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.lang.c
Subject: Re: 31 Character Externals are Maximally Conforming (was Re: effect of free())
Message-ID: <11027@smoke.BRL.MIL>
Date: 12 Sep 89 02:48:08 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>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 70

In article <1989Sep10.234151.14314@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes:
>This follows from the fact that no non-trivial strictly conforming
>programs exist.

That's utterly false.  I write such programs all the time.

>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!

In practice, ANY implementation has to have SOME additional restrictions
beyond the constraints of the Standard.  X3J11 recognized this.

>Any test suite for ANSI C, must impose additional, "reasonable"
>constraints on conforming implementations, constraints which the dpANS
>explicitly refuses to impose.  Hence, failure to pass a test suite
>cannot prove noncompliance with dpANS, only, at most, noncompliance
>with a "reasonable" interpretation of it.

This too is false.  If the test suite indicates the reason for failure
to pass, it should be a simple matter to determine if it's due to the
implementation failing to meet the Constraints and Semantics requirements,
or to a deficiency in the test suite itself (such as being too large for
the implementation).

>The insistence on strict conformance in working code is, therefore,
>pointless.

Not at all.  It's an important part of a viable portability strategy.

>Insisting on 31 significant initial characters in a "reasonably"
>compliant implementation is as "reasonable" an interpretation of the
>standard as can be made.

That too is false.  The Standard is quite explicit about this.  Only
six characters, monocase, of significance in external identifiers is
required of conforming implementations.

>I can imagine some large vendors saying to their rep to X3J11, "Have
>fun, but remember, if you do anything that requires a change to our
>installed base of mainframe OSes, you can kiss a promising career
>goodbye."

This verges on libel.  I've had many off-the-record discussions with
X3J11 members, and never saw any sign of such pressure.  Nearly all
votes on technical issues were by show of hands, with no specific
names recorded, thus no way for employers to know how representatives
were voting the issues.  Certainly there was a deliberate effort to
accommodate the widest feasible range of computing environments, but
in all cases a majority of the committee had to be convinced, so any
narrow special-interest concern would have to be convincingly presented
as beneficial to C programming as a whole before it would be adopted.
I believe that X3J11 members "voted their conscience" most of the time.

>What may be appropriate is another C standard effort, whose charter
>does not allow them to contradict the ANSI Standard, but which allows
>them to extend it, and to further restrict conforming implementations
>than X3.159 was able to do.

I think you have "gone off the deep end" upon discovering that we were
unable (for PRACTICAL, not POLITICAL, reasons) to force ALL conforming
implementations to accept ALL strictly conforming programs.  All that
trying to impose such a constraint would accomplish would be to reduce
the availability of Standard C; in lieu of standard conformance, who
knows what a C implementation would look like on the other systems.
It would be an immense disservice to make the standard unduly restrict
the environments in which Standard C is available.