Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!ptsfa!hoptoad!gnu From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.lang.c Subject: draft ANSI standard: needs your tomatoes Message-ID: <1384@hoptoad.uucp> Date: Tue, 2-Dec-86 03:28:49 EST Article-I.D.: hoptoad.1384 Posted: Tue Dec 2 03:28:49 1986 Date-Received: Tue, 2-Dec-86 08:09:38 EST Organization: Nebula Consultants in San Francisco Lines: 76 [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@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!