Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Do non-trivial strictly conforming programs exist?
Message-ID: <11047@smoke.BRL.MIL>
Date: 13 Sep 89 08:27:31 GMT
References: <1989Sep8.230612.6629@algor2.algorists.com> <12570025@hpclwjm.HP.COM> <1989Sep12.164622.18909@algor2.algorists.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

In article <1989Sep12.164622.18909@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes:
>In article <12570025@hpclwjm.HP.COM> walter@hpclwjm.HP.COM (Walter Murray) writes:
>>With reference to the example in the basenote, a program can
>>be strictly conforming even though it contains TWO macro
>>definitions with 31 parameters in each, can't it?  
>No.  The implementation need execute only ONE program containing ONE
>instance of a 31 parameter macro.

Walter was correct.  The implementation is obliged to provide a
single example that it handles correctly and that stresses all the
minimum limits.  That definitely was the intent of the committee
as I recall the discussion at X3J11 meetings.  The constraints on
strict program conformance are different; as I recall the intent,
strict program conformance was supposed to mean that the program
does not violate any constraint of the standard and does not rely
on any behavior flagged as explicitly "implementation-dependent"
(using these terms in their loose English meanings here).  There
was not supposed to be any guaranteed that a strictly-conforming
program work properly on all conforming implementations, unlike
what 1.7 seems to be trying to guarantee.  It merely would have
the best chance that the Standard could provide of doing so.

>A conforming implementation can: ... as the Rationale says, make
>itself totally unusable in the above ways and a bunch of other ways.

Certainly it COULD be a useless piece of shit.  In which case,
the expectation is that it would not do well in the marketplace.
There are far too many C implementations for ones that exhibit
continued, severe deficiencies to survive.  The "Standard"
imprimatur is not intended to be a warranty of merchantability
or fitness for any particular purpose.  It merely lets you know
that you have the RIGHT TO EXPECT your carefully-coded portable
program to compile and execute with minimum hassle in such an
environment.  That's significantly better than the previous
state of the art.

>> But that doesn't excuse the implementation from accepting a program
>> which contains more than one such instance, does it?
>Absolutely, explicitly and intentionally.

Only "legally" (in the loose sense).  Morally, absolutely not!