Re: Clean up extern inline

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Feb 02, 2007 at 03:30:29AM +0000, Joseph S. Myers wrote:
> On Fri, 1 Feb 2007, Ian Lance Taylor wrote:
> 
> > * Add option -fgnu-extern-inline which indicates that gnu89 "extern
> >   inline" should be used.
> 
> We do need such an option in 4.3 and later because Ulrich will not accept 
> Jakub's glibc patch (he'll only accept header fixes but not fixes to the 
> rest of glibc).  Adding it to 4.1/4.2 seems reasonable if it makes it more 
> convenient for glibc to use this option.

For glibc itself that doesn't matter, glibc's configure would check for
-fgnu89-extern-inline option availability and only use it if present.
But guess it won't hurt to add a nop -fgnu89-extern-inline switch to older
branches that errors out in the -fno-gnu89-extern-inline variant.

> > * If we see an "extern inline" function:
> >   + If -fgnu-extern-inline is used, apply gnu89 semantics.
> >   + Else, if the declaration is in a system header, apply gnu89
> >     semantics.
> >   + Else, if -std=c99 is used, but not -std=gnu99, issue an error.
> 
> I'd add that -fno-gnu-extern-inline should be an error in 4.1/4.2, and 
> more generally in c89/gnu89 modes (the number of language dialects should 
> be minimised).  But adding any diagnostics for this to 4.1 branch would be 
> a mistake; it would make upgrading from 4.1.2 to 4.1.3 unsafe for some 
> users.  (I don't think we should add such deprecation warnings to past 
> release branches once they've had a release from them, at all, ever.)

Yeah, strongly agreed.

> The rules (for 4.3 and later) should be:
> 
> * If !flag_isoc99, gnu89 inline is always used; -fgnu89-extern-inline is a 
> no-op and -fno-gnu89-extern-inline is an error.
> 
> * If flag_isoc99, C99 inline is used unless -fgnu89-extern-inline is 
> specified, in which case (a) if flag_iso, there is an error, (b) if 
> !flag_iso, gnu89 inline is used.
> 
> * Any preprocessor macro always reflects which inline semantics are in 
> use.

IMHO gnu_inline attribute should be kept too, glibc and other library
installed headers need to be usable in all compilation modes and changing
everything to static inline is not desirable.  As ISO C99 inline semantics vs.
GNU89 inline is not just about swapping the meaning of inline vs. extern
inline, but also in ISO C99 semantics adding weird requirements that there
can't be even any prototype with extern keyword the uglification of the
headers would be unacceptable (and, furthermore, any app that would add
their own prototype with extern keyword for a standard function would
have a potential to break, depending on whether glibc decided to inline
optimize it or not).  With -fgnu89-extern-inline addition a macro which
differentiates both modes is a necessity (without it checking for
GCC >= 4.3 and __STDC_VERSION__ >= 199901L was enough to detect ISO C99
semantics and gnu_inline attribute presence).

	Jakub