Re: Clean up extern inline

["Joseph S. Myers" <joseph at codesourcery dot com>]

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.

> * 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.)

> * If we see an "extern inline" function:
>   + If -fgnu-extern-inline is used, apply GNU semantics.
>   + Else, apply c99 semantics.

Changing the definition of gnu89 in this regard is wrong, in any version 
at all.  The gnu89 dialect has the defined semantics (in fact, the option 
should probably be called -fgnu89-extern-inline instead to make it clear 
that gnu89 semantics are being selected).  The future behavior of both 
gnu89 and gnu99 has been promised in the documentation ever since my patch

2001-05-21  Joseph S. Myers  <jsm28@cam.ac.uk>

        * extend.texi: Clarify documentation of extensions included in ISO
        C99.  Prefer C99 terminology and syntax to old GNU terminology and
        syntax.  Add more index entries.  Document mixed declarations and
        code as an extension in C89 mode.  Warn about future changes to
        semantics of inline functions.  Fixes PR other/930.

added the paragraph:

+For future compatibility with when GCC implements ISO C99 semantics for
+inline functions, it is best to use @code{static inline} only.  (The
+existing semantics will remain available when @option{-std=gnu89} is
+specified, but eventually the default will be @option{-std=gnu99} and
+that will implement the C99 semantics, though it does not do so yet.)

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.

-- 
Joseph S. Myers
joseph@codesourcery.com