Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!hplabs!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.std.c
Subject: Re: : Re: __STDC__ and non-conforming ANSI C compilers
Message-ID: <12040011@hpfcdc.HP.COM>
Date: 31 Jan 89 02:52:38 GMT
References: <8809@megaron.arizona.edu>
Organization: HP Ft. Collins, Co.
Lines: 40

> 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