Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclsue!sue
From: sue@hpclsue.HP.COM (Sue Meloy)
Newsgroups: comp.std.c
Subject: Re: Re: Re: __STDC__ and non-conforming ANSI C compilers
Message-ID: <12570003@hpclsue.HP.COM>
Date: 18 Jan 89 19:50:57 GMT
References: <898@ubu.warwick.UUCP>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 21

To me, the question boils down to name space and extensions.
I feel __STDC__ should definitely not be defined unless all 
syntax of the ANSI standard is allowed (prototypes, token pasting, ...).  
Although AT&T apparently thinks differently, I also feel that __STDC__ 
should not be defined if the semantics are different from ANSI.

But, for syntax extensions and name space pollution, I do feel that it
may be reasonable to define __STDC__.  In particular, POSIX requires
additional names that would pollute a strict ANSI name space.  Is it
reasonable to say that __STDC__ should not be defined in a POSIX
implementation?

As for syntax extensions (accepted silently), no strictly-conforming 
program should be affected.  Programs that use the extension would not 
receive a diagnostic, rendering the implementation non-standard, so 
theoretically __STDC__ should not be defined.

Would defining __STDC__ in either of these situations cause problems?
If not, is it OK to define it to 1, or should it be 0?  Doug, you
mentioned that one implementation "guessed wrong" about your intent 
for using __STDC__.  Could you elaborate on the problems it caused?