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

Micah Cowan wrote: > 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 Well, neither your writeup nor mine

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

-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 sy

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

Eric Blake wrote: > the pair 'extern inline' that causes the problem. Are we stuck with just > telling these users that they shouldn't upgrade gcc without also upgrading > their headers, because the old headers are broken with the new gcc? When gcc changed the semantics they also introduced the

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

Eric Blake wrote: > 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? [1] contains a test case. How to modify the glibc headers,

older Linux wchar.h vs. gcc 4.3.x

If you aren't already aware, the (not-yet-released) gcc 4.3 is changing the semantics of 'extern inline' functions to obey C99 semantics when called with std=gnu99. The net result of this change is that functions declared in headers that relied on the old gcc semantics to be inline-only will no