[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

["jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-07 08:18 -------
Subject: Re:  [C99] extern inline is handled wrong in C99 mode

On Sat, 7 Aug 2004, hozelda at yahoo dot com wrote:

> By 6.9 and 6.9.1, every translation unit has exactly one or zero definition for a 
> function. This means that the same translation unit cannot have both an inline 
> and an external def. 

I don't see how you deduce this.  I agree it's the intent, but I see
nothing in the text of the standard that specifically prohibits having
both inline and external definitions in a translation unit, just the
presumption in 6.7.4#6 that there is just one definition of the function
in the TU.  I mentioned this in an aside to my pre-DR#2 that I sent to the
gcc list some time ago <http://www.srcf.ucam.org/~jsm28/gcc/pre-dr-2.txt>.

This would also be one of the incompatibilities between C99 and gnu89, as
GCC has allowed both inline and external definitions while the intent of
C99 seems to be not to allow them.  Thus, one more potential problem to
fix in glibc should C99 inline be implemented in GCC.

> *** [Using this understanding of "reference" ...] Within a function such as 'g' 
> (inline def/ exte link), gcc would need to verify the linkage of every identifier it 
> came across no matter how deeply nested (within a declaration or within a 
> statement). This is right, no? 

Including those inside sizeof.  I don't think this is a tricky
interpretative issue.  If, in the inline definition, the identifier is
used (in the name space of ordinary identifiers) while the internal
linkage declaration is in scope, or declared as extern while that
declaration is in scope (so linking to the previous internal linkage
declaration), this is a constraint violation.  If it is used in another
namespace, or redeclared as an identifier with no linkage, there is no
problem.  If it is declared with external linkage in a scope where the
internal linkage declaration is hidden, this is compile-time undefined
behavior and an error is permitted though not required.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622