Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: draft ANSI standard: needs your tomatoes Message-ID: <5421@brl-smoke.ARPA> Date: Tue, 2-Dec-86 17:56:28 EST Article-I.D.: brl-smok.5421 Posted: Tue Dec 2 17:56:28 1986 Date-Received: Tue, 2-Dec-86 22:17:17 EST References: <1384@hoptoad.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 155 In article <1384@hoptoad.uucp> gnu@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.