draft ANSI standard: needs your tomatoes

[Doug Gwyn]

In article <1384 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>...  I'm calling
>on all of you out there to read it and pick it to pieces, because it is
>not up to the quality of a national standard.  My comments alone will
>not carry enough weight to stop it.  If they get a flood of negative
>comments, they will be forced to revise it and go through another
>public review, when we will possibly get to comment on something close
>enough to a real standard to matter.

John, this is amazingly irresponsible of you.  X3J11 has not been
trying to railroad anything or sneak garbage past the unsuspecting
public, which is what the tone of your remarks seems to imply.

The major purpose of public review is indeed to obtain feedback to
help improve the quality of the standard.  HOWEVER, for this to work,
it is essential that criticisms be basically CONSTRUCTIVE in nature.
A "flood of negative comments" will really not help the process;
careful evaluations accompanied by specific proposals will.

>I think that the low quality of the standard is partly due to its not
>getting enough early review.  I think that if earlier drafts had been
>posted to the net, it would be in much better shape.

Every interested party, including you, had the opportunity to
participate in the drafting process.  Judging by the generally
low caliber of net.lang.c postings over the past few years, I
doubt very much that input from the newsgroup readership would
have helped much.  Most people who really cared about the process
managed to obtain draft copies somehow, and several X3J11 members
monitored the net.lang.c discussions.  I should also point out
that X3J11 includes a large number of top-notch C experts, so
flaws in the draft are not due to ignorance or inexperience.

>In general, I find the draft standard to be the least precise proposed
>standard I have seen.  Most standards start off by defining the model
>of the language environment (e.g. what attributes a name or value can
>have) and then clearly define for every language construct what
>attributes are relevant and how they are modified.  In this standard,
>you have to read the whole thing to make sense of it.  It's like the
>K&R "C reference manual" but 200 pages long instead of 40 pages, and
>written by committee.  ...

Judgements about "precision" are rather subjective.  The draft C
standard seems to me rather precise in comparison to other
standards I have seen.  Your simple model of what is appropriate
breaks down pretty badly if you actually try to follow it for C.

The idea of a formal semantic specification was considered and
decided against; the K&R Appendix A model was chosen deliberately
to make the eventual standard maximally useful to a wide audience.

The fact that a linear sequential reading of the draft can't be
used to specify everything fully is a feature of the C language
itself.  The "Forward references" in the draft are an attempt to
help the reader cope with this.  If the document were a tutorial,
which it explicitly is not, then a different presentation would
be appropriate.

The additional size is due to several factors:
	(1) K&R had ambiguities, omissions, etc. which required
	additional text to clarify.
	(2) X3J11 included additional facilities such as run-time
	library routines, enums, (void *), and function prototypes.
	(3) Appendices, an index, and so forth make the page count
	greater.

> * Many terms are used but are not well defined, or are misused
>   (e.g. "full expression", "lvalue", "object".  Is a character string
>   an lvalue?  Is it an object?)

The quoted terms are defined in the draft.  If you have better
definitions, by all means propose them.

A string is an array of characters (including null terminator) and
is indeed an object.  So is a string literal, which is what I assume
you meant by "character string".  In Section 3.3.1 one finds that a
string literal is an lvalue (among other things).  I determined all
this in less than a minute, simply by using the index (part of the
200 pages you complained about).

> * you can compare (int *) == (void *)
>	   but not (int *) >= (void *).

That's correct.  (void)s have no size.  (void *)s therefore have
limited use.  If you want to argue that sizeof(void) should be 0,
I would agree with you, but it still is not clear how to compare
"magnitude" of pointers to data of different types.

> * you can declare a function to be const or volatile.

That appears to be correct, but it's harmless since they are
meaningful only for expressions that are lvalues.

> * There seems to be no automatic conversion of const to normal or volatile
>to normal, e.g. you can't pass a const char * or a char *const or a
>volatile char * or a char *volatile to a function expecting a char *.
>I presume this is why the type of string constants was not made "const".

If a function formal parameter is non-const (char *), that's because
the function expects to be able to modify the data, so of course
feeding it a const actual parameter (which may be in ROM!) is an
error (actually, "undefined" behavior).  Why should an "automatic"
(usually erroneous!) conversion be silently performed?

The main reason string literals are not const is that some applications
really do overwrite their contents (e.g. mktemp() on UNIX).  The way
the draft ended up, an implementation can choose to make string literal
data ROMmable or not; this was deliberately unspecified.

> * you can't cast a void to type (void).

This is a necessary consequence of the decision that a void expression
has no value (Section 3.2.2.2).  This is essentially the same decision
as that (void)s are not objects.  If you want to dispute that decision,
you need to address all the problems that are raised by having (void)s
be objects.  Do you really think X3J11 didn't consider this issue?

> * sizeof (2+2) is valid, as is sizeof ("abcd"+2).

Yes, they are valid and (at least in the second case) possibly useful.
My pre-X3J11 compiler accepts these, too.

> * sizeof (array) returns the size of a pointer to the first element.
>(sec. 3.2.2.1 switches it to a pointer before sec. 3.3.3.4 can use the array)

That's not what Section 3.2.2.1 says.  The conversion to pointer is
done ONLY in contexts where an lvalue is not permitted (but not for
a string literal used as a char[] initializer).

> * multiple character char constants (e.g. 'abc') are legal and encouraged

They always have been legal in C.  Since they are legal, their
properties had to be defined.  They are NOT "encouraged"; Section
3.1.3.4.Semantics even warns that the value of such a construction is
"implementation-defined", which is like waving a red flag for the
programmer concerned about portability.

I have a problem with the assumed maximum number of bits in a char,
and have proposed an alternative as part of my multi-byte character
proposal.

> * empty arrays are explicitly disallowed

I don't think they were ever legal.

>I wish X3J11 had offerred prizes like the POSIX committee, but I don't
>think they could afford to.

X3J11 is not so frivolous.  If they were to offer prizes, it would
take more careful reading of the draft proposed standard than you
have exhibited to win one.

I'm sure there are errors, oversights, etc.  But let's get some
constructive suggestions based on a thorough understanding of what
is actually in the draft, rather than shoot-from-the-hip flames.