Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: 31 Character Externals are Maximally Conforming (was Re: effect of free())
Message-ID: <11042@smoke.BRL.MIL>
Date: 13 Sep 89 07:46:21 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <2071@munnari.oz.au> <6117@ficc.uu.net> <1989Sep10.234151.14314@algor2.algorists.com> <11027@smoke.BRL.MIL> <1989Sep12.160023.18723@algor2.algorists.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 67

In article <1989Sep12.160023.18723@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes:
>>>I won't repeat the argument which shows this, but it is based on the
>>>fact that 2.2.4.1 accepts as conforming many implementations which
>>>impose extra limits on the program, so that few, if any, programs
>>>will be acceptable to all implementations.
>>But that's not the criterion for a strictly conforming program!
>1.7 "A strictly conforming program ... shall not produce output
>dependent on any ... implementation defined behavior, and shall not
>exceed any minimum implementation limit."

That means "any minimum implementation limit as specified by this
standard", not "the most miserable possible conforming implementation".

>>In practice, ANY implementation has to have SOME additional restrictions
>>beyond the constraints of the Standard.  X3J11 recognized this.
>And a lot more.  From the Rationale 2.2.4.1: "a deficient [ but
>conforming ] implementation could ... succeed in being useless."  The
>Rationale also (1.7) says that the intent was that strictly conforming
>programs not be required to be fully, only maximally, portable, among
>conforming implementations, but X3J11 did not write the definition of
>strictly conforming in 1.7 of the standard itself anywhere near
>loosely enough for that to be true.

Programming for portability is an art; it cannot be forced by any
amount of legislation.  Certainly, a strictly conforming program
could be devised that would place such heavy demands on compiler
symbol tables, for example, that it could not be successfully
compiled on the largest existing computer.  That is why "strict
conformance to the standard" is not 100% synonymous with
"totally portable to all conforming implementations".  The idea,
as I said earlier and is also addressed by the Rationale, is for
"strict conformance" to serve as an important guideline for
writing maximally portable C programs.  That does not mean that
there are not other considerations that also need to be addressed.

>So we would have the tester report: "The implementation failed to
>compile the test suite due to its size constraints, therefore the
>implementation passes!"

Get real.  That's not what C conformance test suites actually do.
A realistic message might be "TEST # 1234: implementation fails
to perform the usual arithmetic conversions properly in this
case: ..."  The idea is to test the grammar, constraints, and
semantics supported by the implementation.  A properly-designed
conformance test suite steers clear of pushing all the required
minimum limits at the same time; it is the implementor's
responsibility to provide the one example program that meets all
these limits simultaneously as called for by the standard.  That
sample program is to be inspected as one conformance criterion.

>dpANS does force ALL conforming implementations to accept ALL strictly
>conforming programs, at least as far as implementation limits go ...

Walter Murray pursued this thread in comp.std.c.  I now admit to not
knowing what distinction  was intended between "accepting" a program
and "translating" and guaranteeing executability for a program.  The
two sets of relevant wording in the proposed standard seem to be at
odds on this.

>The work of X3J11 takes us out of that realm
>and a few quibbles over language are a small price to pay for that.

These are important issues, perhaps worth formally requesting
clarification from X3J11.

Disclaimer:  I'm merely expressing my own notions and confusion,
not necessarily X3J11's.