Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!husc6!rutgers!noao!arizona!gmt
From: gmt@arizona.edu (Gregg Townsend)
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers
Summary: __STDC__ should distinguish new C from old C.
Keywords: ANSI C, __STDC__
Message-ID: <8366@megaron.arizona.edu>
Date: 14 Dec 88 19:09:31 GMT
References: <3236@pegasus.ATT.COM> <9167@smoke.BRL.MIL> <12643@bellcore.bellcore.com>
Organization: U of Arizona CS Dept, Tucson
Lines: 25

In article <3236@pegasus.ATT.COM> hansen@pegasus.att.com writes:
> What do people think a compiler should do with __STDC__ if it is not
> strictly conforming?

It's important to consider how __STDC__ can and will be used.  I help to
maintain a software system that runs under a large number of environments.
I'd like to be able to check __STDC__ to see if I can (& must) use newstyle
token pasting, "void *", prototypes, and other such things.

If a compiler isn't strictly conforming only because it has an "asm" keyword
or similar extension, then undefining __STDC__ isn't going to help anyone who
uses a variable named "asm".  I don't see how undefining it helps ANYTHING
in this case.

Clearly, a strictly conforming compiler should define __STDC__ as 1, and a
K&R compiler shouldn't define it.  If a compiler is essentially "ANSI C
with extensions", and it can reasonably be expected to process most
conforming programs without problems, then it's less misleading to define
__STDC__ than not.  The useful distinction is "K&R" vs. "ANSI", not "pure
compilers" vs. "all others".

I agree that compilers shouldn't break programs by adding gratuitous
extensions.  But if they do, undefining __STDC__ won't help.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    +1 602 621 4325      gmt@Arizona.EDU       110 57 16 W / 32 13 45 N / +758m