This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
- To: Linus Torvalds <torvalds at transmeta dot com>
- Subject: Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Fri, 12 Feb 1999 18:44:09 -0500
- cc: egcs at egcs dot cygnus dot com
On Fri, 12 Feb 1999 15:31:05 -0800 (PST), Linus Torvalds wrote:
>And yes, before people say that gcc documentation said that "extern
>inline" was documented to be _almost_ like a macro, then instead of being
>a language layer, please consider for a moment using your brains for
>something else than syntax, and using them for asking yourself "what is
>reasonable for a programmer"?
For most uses, I think the existing behavior of "extern inline" is the
reasonable behavior. We use it heavily in libc - take a look at
string.h sometime (actually bits/string.h, bits/string2.h). That code
absolutely relies on the behavior of `inline if possible, otherwise
generate a reference to the real function'.
There is legitimate code where you must inline for correct behavior,
but it's rare enough that I think it's reasonable to do something
special, like an __attribute__ declaration. It's not surprising to
find examples of that in the kernel, which has to do more "strange
stuff" than user code.
zw