This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: kernel-2.2.1-undefined references


   Joe Buck (jbuck@Synopsys.COM) wrote:

   It might be appropriate to generate an error, not a warning, if
   "extern inline" fails to inline, since it is clear from the documentation
   that this is not a mere hint.

I may be quoting you out of context, but if you really are suggesting
that failing to inline an ``extern inline'' function should generate
an error (or even a warning without explicitely asking about warnings)
please think again.

The gcc documentation contains the following paragraph:

      This combination of `inline' and `extern' has almost the effect of a
   macro.  The way to use it is to put a function definition in a header
   file with these keywords, and put another copy of the definition
   (lacking `inline' and `extern') in a library file.  The definition in
   the header file will cause most calls to the function to be inlined.
   If any uses of the function remain, they will refer to the single copy
   in the library.

This is exactly how we use ``extern inline'' in the GNU C Library and
the Hurd.  Since even some of the standard ANSI C headers contain
``extern inline'' function (of course properly marked as extensions
and only if gcc/egcs is used) generating errors could possibly make
compiling almost any program impossible, and generating warnings would
be pretty annoying.

The documentation on ``extern inline'' may not be entirely clear, but
the above paragraph is crystal clear.  ``extern inline'' is a hint,
and not providing an additional definition without `inline' and
`extern', is asking for trouble.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]