Re: c/10488: Implementation of extern inline is exactly backwards

["Joseph S. Myers" <jsm28@cam.ac.uk>]

The following reply was made to PR c/10488; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: David.Moore@intel.com
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c/10488: Implementation of extern inline is exactly backwards
Date: Fri, 25 Apr 2003 09:36:13 +0100 (BST)

 On Fri, 25 Apr 2003 David.Moore@intel.com wrote:
 
 > When extern inline is used on a function definition, a body for that
 > function must be layed down in the current compilation unit binary. When
 > just inline is given, no body should be layed down.
 
 We are aware of this.  See c99status.html.  The intention is that for
 compatibility the existing semantics will remain in gnu89 mode and the C99
 semantics will be provided in c99/gnu99 modes.  Patches to implement the
 C99 semantics (including the necessary fixincludes work to fix the many
 different versions of installed glibc headers that expect the old
 semantics, and including thorough testcases) are welcome; I am not aware
 of anyone working on this.
 
 > 6.7.4 says that if all the declarations of a function are "inline" (not
 > "extern inline") the compilation unit does not provide an external
 > definition for the function. That is, the body is not layed down.
 > Otherwise, if the extern storage class specifier is used, a body must be
 > layed down as per section 6.9.
 
 And note this means it is not as simple as:
 
 > Fix is probably simply a matter of flipping a condition but beware that
 > there are uses of this in the gnu C header files where the usage is
 > believed to also be backwards.
 
 (apart from the need to condition on flag_isoc99) because, for example, a
 function can be defined inline (without extern) and a subsequent
 declaration (as extern or without inline) then means an external
 definition must be provided.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk