Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!usc!merlin.usc.edu!nunki.usc.edu!jeenglis
From: jeenglis@nunki.usc.edu (Joe English)
Newsgroups: comp.lang.c
Subject: Re: MSC __STDC__ strange value
Summary: MSC has language extensions, so it's not really __STDC__
Message-ID: <6856@merlin.usc.edu>
Date: 5 Dec 89 10:55:13 GMT
References: <223@bohra.cpg.oz>
Sender: news@merlin.usc.edu
Reply-To: jeenglis@nunki.usc.edu (Joe English)
Organization: University of Southern California, Los Angeles, CA
Lines: 34

ejp@bohra.cpg.oz (Esmond Pitt) writes:
>For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so
>#if __STDC__
>
>yields a different result from
>
>#ifdef __STDC__
>
>Why?

MSC (and many other compilers) support extensions to
the Standard (far pointers, etc.)  A common convention
is to define __STDC__ as 1 when operating in
strict-conformance mode (extensions disabled), and as
0 otherwise.  That way you can use "#ifdef __STDC__"
to determine if, e.g., function prototypes are
available, and "#if __STDC__" to determine if the
compiler is strictly conforming (no extensions, no
surprises.)  MSC's default mode probably leaves the
extensions turned on.

This is just a convention, by the way; it's not
required by the Standard, and it's not strictly
portable.  It's not required because:  if the compiler
supports extensions, it's not strictly conforming, and
if it's not strictly conforming, the Standard has no
say over what it does.  As far as I can tell, this
practice follows both the letter and the spirit of the
law, being useful without really breaking the rules.


--Joe English

  jeenglis@nunki.usc.edu