Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26/text0053.txt

Text File | 1992-02-21 | 4.5 KB | 88 lines

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>...  For example, the C standard uses the
>term ``compatible type'', while the ARM uses the phrase ``the same
>type''.  The editorial changes involve using one term or the other
>consistently throughout the document.

You seem to be implying that these terms denote the same concept.
However, both terms have (distinct) meanings in the context of the
C standard.  I hope the actual "editorial" changes involve
determining which (if either) is intended for each case individually.

>...  Sensitive to the experience of
>the C committee (where a J. Hansberry invoked the formal procedures of
>ANSI to delay the publication of that standard by over a year), the
>Extensions group is going out of its way to give an unbiased hearing
>of every proposal submitted.

This seems to imply that Mr. Hansberry was not given an unbiased
hearing.  To the contrary, X3J11 bent over backward to consider
Mr. Hansberry's comments on the draft proposed C standard.  The
whole "Hansberry incident" arose when the parent administrative
body, the CBEMA X3 Secretariat, mislaid Mr. Hansberry's comments
so that they were not forwarded to X3J11 until some time after
the review process for public comments had closed and what were
thought to be the final revisions to the proposed C standard had
been made by X3J11.  Out of concern for proper consideration of
ALL properly submitted public review comments, X3J11 reopened the
review process at a subsequent meeting and Mr. Hansberry was given
the floor to explain his concerns at length.  The committee found
that approximately half of Mr. Hansberry's suggestions had already
been addressed through previous responses to other public comments,
and the remaining half were infeasible or fell outside the charter
of X3J11, so in fact no further editorial changes were required as
a result of this extension of the public comment review process.
However, X3J11 certainly would have made additional changes had
they been found necessary as a result of Mr. Hansberry's comments;
throughout the public review process I in particular, as editor of
the official documents responding to the public comments, have been
especially concerned with ensuring fairness of the process, and I
think that X3J11 did an excellent job of fairly considering EVERY
comment received during the public review of the three draft
proposed C standards.

Despite this extraordinary effort to afford his comments a fair
hearing, Mr. Hansberry exercised his right to appeal X3J11's
decisions concerning his comments.  Ultimately his appeal was
found to be groundless, but the appeal process did delay final
ratification of the C standard by nearly a year.  As best as I
could determine, Mr. Hansberry's main gripe was that X3J11 had
not added a sizeable library of extensions to make his job of
programming real-time systems easier.  We did point out that this
was not within our charter, that the bulk of the committee lacked
sufficient expertise in real-time systems, and that there was
a POSIX group tasked with working on such extensions, to which
such suggestions should be addressed, but apparently Mr.
Hansberry decided to try to force X3J11 to tackle this area.
Fortunately for the C programming community in general, the scope
of the C standard remained pretty much what it had been all along
(with the notable exception of the fairly late addition of support
for "internationalization").

>   - adding 8-bit (i.e. international) characters in
>     identifiers

As phrased, this is too narrow a view of the concept of native-
language identifiers.  X3J11 did consider this issue in considerable
detail, ultimately deciding that all that the standard should promise
would be a minimum set of characters allowed in portable programs.
Other characters can be supported as nonportable extensions, but
that seemed to be beyond the scope of a universal standard, which
necessarily must address the subset of implementation support that
can be guaranteed across ALL environments.

The one improvement that could have been made to this in the C
standard would have been to not require any diagnostic when such
extended identifiers are used in a (not strictly) conforming program.

If you guys do decide to pry open this can of worms, don't forget to
allow for multibyte character encodings (for Kanji etc.).  The idea
that all relevant natural-language characters can be encoded in a
single 8-bit scheme is extremely parochial.


Volume-Number: Volume 26, Number 64