> Perhaps we should
> #define unix unix

> :)

The smiley hints you know this isn't sufficient, but for anyone saying "aha!":

this would break an ANSI C strictly conforming program which contains

#ifdef unix
/* code which is not compilable but at least keeps the preprocessor happy */
#else
/* real, useful code */
#endif

("#define unix unix" probably also trips up non-strictly-conforming code that
assumes the environment DOES define it, but as 1 or 0, so you still don't win.)

Now, it's probably the case that the preprocessor symbol "unix" will only
trip up verification suites written to deliberately expose that common failing,
but there's little point in claiming that one has a compiler which is fully
ANSI conforming "except for all the little stupid things", because that tells
no one anything useful.  Either go for genuine conformance or don't bother at
all; and I personally see genuine conformance as a good thing.

Yeah, it kind of sucks that not defining "unix" means that a bunch of existing
packages won't compile; lots of software broke when "a =- 1;" stopped meaning
decrement a by 1. [*]  However, just defining "unix" *doesn't* tell someone
whether or not their package compiles.  Full ANSI conformance means that, at
least for strictly conforming applications, you *do* offer a firm promise that
a package will compile and run.

    Of course, it has been noted many places that "strictly conforming" is
    rather too tight a straightjacket in which to code, even if you gloss
    over the fact that even printf() renders a program not strictly conforming.
    [**]  (At one point, on comp.std.c, I suggested that it might be useful
    to try to devise a firm notion of a "firmly conforming" program (or some
    name like that), but the general consensus was that things get slippery
    WAY too fast once you start allowing implementation defined behavior into
    your category.  And, of course, the notion of a merely "conforming"
    program is useless (defined as any program which is accepted by any
    conforming compiler; if a conforming C compiler can recognize that it
    has been asked to compile a BASIC program and then compiles it AS as
    BASIC program (after the obligatory message, since a number is not a
    legal first token in a C compilation unit), then that BASIC program is
    a "conforming C program"!).

    However, most programmers who really understand ANSI C well enough to
    be allowed in the same room as a C compiler generally know where they've
    strayed from strictly defined to implementation defined (and have
    flagellated themselves mercilessly each time they stray beyond THAT),
    so "conforming C compiler" still represents a useful label.

[*] "You young whippersnappers haven't got any sense of history, why in MY day
..."

[**] How?  Your program now depends on characteristics of an implementation
which are not specified in the standard, like whether or not there even IS
an output device for stdout to go to (think embedded systems here).