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

[Jeffrey Kegler]

In article <6117 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:

>How about the limitation in significant characters in external
>symbols? That one's much more irritating.

Actually, as a corollary to a discussion I initiated in comp.std.c,
use of 31 significant characters in externals is as conforming to ANSI
C as anything.

This follows from the fact that no non-trivial strictly conforming
programs exist.  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.  (The
clearest explanation of this is in the Rationale.)

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.

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

Insisting on 31 significant initial characters in a "reasonably"
compliant implementation is as "reasonable" an interpretation of the
standard as can be made.  The number 31 makes externals orthogonal
with internal identifiers and macro names.  The dpANS explicitly
(Footnote 8 and the Rationale 2.2.4.1) calls upon vendors to be
expansive in their interpretation of system limits.  Stricter limits
on externals are explicitly deprecated in 3.9.1.

Given the politics of X3J11, it might have been unreasonable to expect
more of the dpANS.  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."  A usable definition of strict
conformance may not have been possible.

I think the most important thing dpANS had to do was avoid imposing a
burden on future compilers and standards.  In this (difficult) task,
they succeeded.

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.  Given the basis laid by dpANS, this
effort will be made far easier.
-- 

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