Re: older Linux wchar.h vs. gcc 4.3.x

[Micah Cowan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eric Blake wrote:
> We will probably start seeing reports like this more frequently as gcc 4.3 is 
> adopted, especially since gnulib projects tend to prefer std=gnu99 when a gcc 
> compiler is detected.  Can anyone think of a way to detect broken system 
> headers that were relying on 'extern inline', in such a way that we can make 
> the gnulib wrapper headers nuke those troublesome declarations out of the 
> headers?  You can't really define away 'extern', nor 'inline', as both terms 
> have distinct semantics that would break when used in isolation; it really is 
> the pair 'extern inline' that causes the problem.

Note that just nuking declarations of "extern inline" is not really an
appropriate solution, as it has a legitimate meaning for users of C99,
so authors of software that were written post-gcc-4.3 may have written
it, intending to get the C99 semantics (which are identical to current
gcc's behavior for "inline" without either of "static" or "external": an
external definition will be created, but inline definitions will be used
where available).

Perhaps the best practice going forward, would be to allow feature
testing that could produce macros corresponding to each desired
behavior. For instance, programmers could be expected to use a symbol
like "inline_only" to mean that no external definitions should be
generated; and "inline_and_external" to mean that it should be available
for inlining, and that an external definition would also be generated.

These would correspond to the following values, for traditional GCC and C99:
                        Trad. GCC       C99
                        --------------  ---------------------------
inline_only             "extern inline" "inline" or "static inline"*
inline_and_external     "inline"        "extern inline"

* AFAIK, there is no way to get exactly the semantics, in C99, of
traditional GCC "extern inline" semantics; my reading of the standard is
that if the function's address is taken, the definition should exist, so
 "inline" and "static inline" are both equivalent to traditional GCC
"static inline".

I don't think "static inline" would need a separate such keyword, as
that combination of keywords has the same meaning in both traditional
GCC and C99, and AFAIK in any other inline-extended C implementations as
well.

Several years ago, I began work on explaining the differences between
C90, C99, and common vendor extensions; I never finished, but the
section on inline functions may be helpful:
http://micah.cowan.name/tech/c-changes.html#N0.238

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGuQu37M8hyUobTrERCDF5AJ9kLB/tpYo8Leo/c6uaRM/1SE99sQCffKoY
Ud/IEjkG6d5LKIcDAsTxT2Y=
=knn6
-----END PGP SIGNATURE-----