[PATCH] Handle gcc -std=c99 -D_XOPEN_SOURCE=600 [BZ #284]
Roland McGrath
roland@redhat.com
Mon Aug 2 20:47:00 GMT 2004
> On Fri, Jul 23, 2004 at 01:19:46PM -0700, Ulrich Drepper wrote:
> > Joseph S. Myers wrote:
> >
> > > c99 is the name of the compiler to "accept source code conforming to the
> > > ISO C standard". For example,
> >
> > And once -D_POSIX_C_SOURCE=200112L is defined all this ISO C nonsense
> > must be completely out of the way. No __STRICT_ANSI__, since non-ISO C
> > stuff is used. The same applies to a few other defines. Only if none
> > is defined can this silly strict ISO C business take place.
>
> I guess it all depends what exact meaning __STRICT_ANSI__ is supposed to have.
> Either its definition chooses only ISO C90 (resp. C99) features in the
> headers, or it can be combined with other feature set macros with the result
> of a union between ISO C90 (resp. C99) features and features selected by
> the other feature macros.
> The __STRICT_ANSI__ documentation in info gcc doesn't seem to favor either
> of these definitions, at least in my reading.
I think this bit here:
The `-ansi' option does not cause non-ISO programs to be rejected
gratuitously. For that, `-pedantic' is required in addition to
`-ansi'. *Note Warning Options::.
leans in the direction of allow combination of -ansi with feature macros.
However, I think it is also reasonable to say that -ansi is a bit archaic.
The important useful case is when someone wants to compile their program
and ensure it is strictly conformant to POSIX, i.e. using non-ISO-C
interfaces specified by POSIX, but not using C language extensions. As I
understand it, this is supported just fine with -std=c99
-D_POSIX_C_SOURCE=something. So I don't off hand see the need for people
to use -ansi.
More information about the Libc-hacker
mailing list