Messages in this thread | | | From | Albert Cahalan <> | Subject | Re: Current Status | Date | 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.
| |