mike@arizona.edu (Mike Coffin) (01/21/89)
Well, I'm bowing out. It is clear to me that __STDC__ has no
practical application as far as porting code goes. Compiler writers
that follow the letter of pANS will cause it to be undefined at the
slightest pretext, while others will set it to 1 if they consider
their nonconformance to be inconsequential. Or maybe set it to 0,
or maybe "__ALMOST__," or "__PRETTY_CLOSE__." Of course, there will
be as many definitions of "inconsequential" as there are compiler
writers. (A really honest compiler writer would never turn on
__STDC__ until he was convinced his compiler had no bugs, I suppose.)
The practical significance is that if I actually put "#if __STDC__" in
a program, I would have to put "ifdef __almost_STDC__" in the #else
clause anyway. And of course it would contain exactly the same code,
since I have no idea whether the compiler turned off __STDC__ for a
truly insignificant reason, or because this is really a FORTRAN
compiler named cc.
So, it's back to specifying compilation environments in the makefile.
I look forward to the day when there are no more "old" C compilers to
worry about, but I suppose by then we'll have a new standard to deal
with.
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike
Tucson, AZ 85721 (602)621-2858rml@hpfcdc.HP.COM (Bob Lenk) (01/31/89)
> 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@hplabs.hp.com