Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!att!att!cbnewsi!cbnewsh!daw
From: daw@cbnewsh.att.com (David Wolverton)
Newsgroups: comp.lang.c
Subject: Re: How ANSI is TC++?
Message-ID: <1990Nov2.225313.344@cbnewsh.att.com>
Date: 2 Nov 90 22:53:13 GMT
References: <116@nazgul.UUCP> <5940044@hpcupt1.cup.hp.com> <131@nazgul.UUCP>
Distribution: usa
Organization: AT&T Bell Labs, Lincroft, NJ
Lines: 17

In article <131@nazgul.UUCP>, bright@nazgul.UUCP (Walter Bright) writes:
> A lot of people talk about "100% ANSI C compliance". This is impossible,
> as it implies there are *no* bugs in the compiler. We all know this
> is unattainable (by any known technology!). The best one can say is
> it passes so-and-so's test suite, or was validated by such-and-such
> outfit.

And/or, that the vendor's _intent_ is to produce a 100% ANSI C compiler.
An example is the SVR4 compiler, which, while it probably contains bugs,
is intended to be ANSI compliant.  Compare this to, for example,
the THINK C compiler on Macs, which supports some "ANSI features" such
as prototypes, but is not claimed to be an ANSI compiler.  Since
marketing droids can influence product claims, one should of course
approach all such claims of intent with a good deal of skepticism.

Dave Wolverton
daw@attunix.att.com