Re: Current Status

Albert Cahalan (albert@ccs.neu.edu)
Fri, 22 Mar 1996 11:05:41 -0500 (EST)


> : The compiler must support this keyword, and many do.
> : The kernel is not, was not, and will never be ANSI C.
>
> "inline" is not in the ANSI C standard (C-89 in case they went off and
> did another turn while I wasn't looking). Therefore, the compiler
> needn't support it. gcc -ansi, for example, will not support it.
>
> Also, many *PROGRAMS* that are strictly ANSI-C compliant use the
> kernel headers indirectly. These fail to compile with gcc -ansi.
> They shouldn't. That's why inline needs to be mapped to __inline__.
>
> Other than it looks ugly, is there a good reason to not do it?

I think __inline__ will work because gcc uses it to escape ANSI.
The point is that it will not conflict with POSIX identifiers.
See what __inline__ does with Think C and Turbo C.

Since __inline__ is so ugly, that is reason enough.
Removing it does not help Think C compile with Linux headers!

When programs fail to compile with gcc -ansi, it means that the
header file did not use #ifdef to remove inline functions and
substitute library functions. It also means that to programmer
is using something they should not: see the gcc man page.
It tells you that -ansi does not check for ANSI compliance!
Enable all the warnings instead, and maybe buy a proper tool.

Many of us like readable source code. That means adding comments,
using typedef to keep "struct" out of functions, and avoiding
extra underscores. "__inline__" has four of the damn things.