: Re: __STDC__ and non-conforming ANSI C compilers
Bob Lenk
rml at hpfcdc.HP.COM
Tue Jan 31 12:52:38 AEST 1989
> I've since acknowledged that so long as the predefinition is being done
> explicitly by the compiler user, not automatically by the compiler, it
> would be most usefully considered as shorthand for editing all the
> sources to temporarily "#define xyz 1". Therefore that would not be
> a "predefined" identifier in the ANSI C sense and would not require that
> __STDC__ be changed from its normal value (1, 0, not defined, whatever).
>
> On the other hand, if the compiler automatically predefines macros in
> the application's reserved name space, or if it automatically predefines
> macros in its own name space that cause other identifiers in the
> application's name space to be usurped (e.g. _POSIX_SOURCE), then I
> definitely want __STDC__ to NOT be set to 1.
The line may not always be clear between the two. For example, suppose
an implementor documents that
ansicc -X
is equivalent to (a shorthand for)
ansicc -D_POSIX_SOURCE
or perhaps that
ansicc -V
is equivalent to
ansicc -D_POSIX_SOURCE -D_VENDOR_SPECIFIC_SOURCE
Granted, it would be possible for the implementor to turn off the
definition of __STDC__ or change its value to 0 when invoking those
options. I'm not sure how application portability is served by doing
that. If the user has source that might be impacted by the namespace
pollution, surely (s)he would not choose to invoke the compiler with
those options.
Bob Lenk
hplabs!hpfcla!rml
rml%hpfcla at hplabs.hp.com
More information about the Comp.std.c
mailing list