31 Character Externals are Maximally Conforming (was Re: effect of free())

[Jeffrey Kegler]

In article <11027 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <1989Sep10.234151.14314 at algor2.algorists.com> jeffrey at 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!

1.7 "A strictly conforming program ... shall not produce output
dependent on any ... implementation defined behavior, and shall not
exceed any minimum implementation limit."  Hence the mimimum
implementation limits are the criterion for a strictly conforming
program.  The more latitude for the implementor, the less for strictly
conforming programs.  [ Aside: a curious exception here is reserved
for programs which produce no output. ]

Further on in 1.7.  "A conforming hosted implementation shall accept
any strictly conforming program."  Similar language follows for
free-standing programs.

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

>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).

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

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

dpANS does force ALL conforming implementations to accept ALL strictly
conforming programs, at least as far as implementation limits go
(which is where the severest restrictions are).  In so doing, it
defines strict conformance out of existence.  This may have been a
good trade off (or the language in 1.7 may have been unintended), but
in any case, the trade off was made.

Let me apologize to those who dislike this sort of lawyerly quibble
over words (and to any who might think I do it as a personal attack on
anyone).  As we go from working exclusively with implementations, to
using standards, this sort of argumentation is inevitable.  C
portability previously was all in the eyes of some greybeard who
remembered the Frobnitz compiler for the Kludge computer would not
handle that construct.  The work of X3J11 takes us out of that realm
and a few quibbles over language are a small price to pay for that.
-- 

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeffrey at algor2.ALGORISTS.COM or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090