draft ANSI standard: needs your tomatoes

John Gilmore gnu at hoptoad.uucp
Tue Dec 2 18:28:49 AEST 1986


[This is posted to comp.lang.c because mod.std.c seems to be dead.  Love
those mod groups!]

I am afraid that, since this is the last mandatory comment period for
the draft proposed ANSI C standard, the current document, or something
like it, will become the first and only C standard.  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.

Be sure to print out your comments and send them in; don't just post
them.  The first page of the standard specifies that comments should be
sent to:
	X3 Secretariat/CBEMA, 311 First St NW #500, Washington DC 20001
with a copy to:
	Board of Standards Review, ANSI, 1430 Broadway, NY NY 10018
The committee requests that you number your comments, starting with 1,
and indicate the relevant section number in each comment.

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.

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.  For example, to determine what constraints are
on order of execution, you can turn to 3.3, but there are exceptions in
3.5.2.4 under "volatile", commentary in 3.6 under "statements", more
constraints in 4.7 under "signal", and others elsewhere (that I can't
find right now!  That's the problem).

The preceding 4 messages in comp.lang.c are just the tip of the iceberg;
they were found within about 5 hours of reading (partly with Guy Harris),
and we only covered a tenth of the document.

Other things that I will comment on when I've researched them better:

 * 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?)

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

 * you can declare a function to be const or volatile.
 
 * 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".

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

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

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

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

 * empty arrays are explicitly disallowed

I wish X3J11 had offerred prizes like the POSIX committee, but I don't
think they could afford to.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore at lll-crg.arpa
Call +1 800 854 7179 or +1 714 540 9870 and order X3.159-198x (ANSI C) for $65.
Then spend two weeks reading it and weeping.  THEN send in formal comments! 



More information about the Comp.lang.c mailing list