Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!rutgers!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: ANSI C -- miscellaneous suggestions Message-ID: <5458@brl-smoke.ARPA> Date: Mon, 15-Dec-86 14:40:02 EST Article-I.D.: brl-smok.5458 Posted: Mon Dec 15 14:40:02 1986 Date-Received: Wed, 17-Dec-86 18:53:33 EST References: <112@decvax.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 201 In article <112@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >Page 1, line 14. The standard should specify the total list of words >reserved to the compiler and its libraries. While this would be "nice", one can pretty much find this out from the index, and the standard isn't intended to be either a tutorial or a user reference manual. I would hope that vendors and textbook authors will consider providing such a list. >Page 6, line 40ff. It is unclear whether the main() function may be >declared or invoked with more than 2 parameters. I thought this was clear: main() can be defined with either 0 or 2 parameters. Other schemes are not defined, which allows extensions such as UNIX's envp but does not mandate them for all implementations. (Note that envp is not normally necessary, given getenv().) >Page 7, line 12. Must the string in argv[0] be modifiable? That's what the draft says. Is this a problem? >Page 10, 27. The horizontal tab, vertical tab, and form feed characters >are not needed by the language. The standard should declare that >horizontal tab is identical to space except in character and string >literals, and vertical tab and form feed are everywhere identical to newline. There are several flavors of whitespace in C (including the preprocessor). Some generalization was done where possible; did we miss any? >Page 11, lines 29ff. The standard should specify the internal representations >for the predefined escape sequences for implementations that use the >USASCII or Latin 1 alphabets, So long as we don't mandate ASCII/ISO character sets, this is infeasible. >Page 12, line 29. The minimum significance for external identifiers >should be changed to ``6 significant monocase initial characters in >an external identifier.'' Section 3.1.2 permits implementations to ignore case distinctions. 2.2.4.1 is merely to establish that at least 6 significant characters can be used in external identifiers simultaneously with meeting other implementation limit requirements, and nothing is gained by mentioning case-mapping in this context. >Page 14, line 20ff. FLT should be FLOAT. DBL should be DOUBLE. etc. As >the first 31 characters of macro definitions are significant, there is no >need to sacrifice legibility (and maintainability) for consiseness. That would be nice, but we also have SHRT_MAX, for example, which is defined in a header that is shared between two standards bodies and is therefore difficult to redefine. (It's also possible that these names were chosen to agree with the new Fortran standard; I forget.) >Page 26, line 13. The exceptions (the characters that may not appear >in string literals) should include the vertical tab character >and the form feed character, as these are equivalent to newlines. Where are these characters declared to be "equivalent to newlines"? >Page 74, line 28. Horizontal tab does not have an independent existance >during preprocessing. The example should note that comments may preceed >or follow the # that introduces a preprocessing directive. Section 2.1.1.2 (Translation phases) states that an implementation MAY retain distinct white-space characters at the point of preprocessing. However, comments must have been turned into single space characters at that point. >Page 75, line 36. An arithmetic error in an #if expression (such as divide >by zero) shall result in a diagnostic error message. However, a sequence >such as: > > #if (foo == 0) ? 0 : (10 / foo) > >should not result in a diagnostic error message for any value of foo. [The page/line reference seems wrong.] I think the error handling is already implied by the syntax, but perhaps explicit wording would help. (Note that the example is correct code and should not cause a diagnostic in any case.) >Page 82, line 24ff. I would recommend the following clarifications to >the definition of the predefined macro names: > > __LINE__ The line number shall be as defined in section 3.8.4, > page 81, line 30. That's already my understanding of the draft. > __FILE__ There is no presumption that this string can be used to > open a file during execution of the program. That's the way it is now. The sources clearly need not even exist in the run-timem environment! > __DATE__ Neither this value nor the value of __TIME__ change during > compilation. That might be nice, but how important is such a constraint on implementations? I bet there even are people who would prefer the __TIME__ clock to continue to tick during compilation. >A predefined name should be redefinable (by #undef). (The identifier >"defined" may not be redefined.) No, since these names begin with underscore, the user cannot safely redefine them anyway; they're not in his "allowable name space". >Page 83, line 15ff. Function prototypes with separate parameter identifier >and declaration lists offer a better environment for documentation than >the more concise function prototype format. I would strongly recommend >that they not be marked obsolescent. The intent is to eliminate any requirement that old-style function parameter declarations be supported in a future revision of the standard. The only way (it appears) that we can do that is by calling them "obsolescent" in a previous draft. >Page 85, line 35. The ability to redefine any function declared in >a header as a macro may break existing programs that write, e.g., > > #include > extern long rand(); > >If rand() is declared as a macro, First of all, I doubt that existing programs #include . When adding such an #include to existing source, you should also remove any explicit redundant declarations (except when they are really necessary, in which case use #undef or one of the other usual tricks to force use of a genuine function). I'll be among the first to admit that this approach has its problems, but I don't know of anything better. If you can suggest a better way to handle this, please write it up and mail it in to ANSI. >Page 89, line 13 (footnote 64): The Standard should note that, in an >implementation that uses the Latin 1 character set, the printing >characters are those whose values lie from 0x20 through 0x7E or from >0xA0 through 0xFF. Control characters are those whose values lie from >0x00 through 0x1F, 0x7F, or from 0x80 through 0x9F. The ranges for the other > macros should be similarly extended. > >Page 91, line 46ff. Note that, in a Latin 1 environment, the ispunct() and >isspace() functions should test for the non-breaking space at 0xA0. No particular character set is required, so we can't make such remarks in the standard itself. Perhaps the Rationale should give such examples. >Page 102, line 46ff. If longjmp() is called from a signal handler, volatile >objects may have indeterminate values as they cannot always be updated by >atomic (one machine cycle) operations. It is unrealistic to require an >implementation to lock interrupts before modifying a volatile object. The >Standard should note that volatile objects are indeterminate when longjmp() >is called from an interrupt or signal handler. I don't know that anything needs to be said about this. The only object for which atomic operations is guaranteed is sig_atomic_t. [longjmp() vs. signal handlers was discussed in a previous note] >Page 128, line 7. Is one character of pushback guaranteed even before >anything has been read from the stream or after end of file or error? >The standard should be clarified on this point. (I don't care either way, >but would prefer permitting one character pushback at any time.) Yes, since this is not specifically excepted it is required. >Page 140, line 21ff. Predefined values for "successful termination" >and "unsuccessful termination" (argumemts to exit()) should be provided. Done at last week's meeting, via a compromise solution that requires that 0 also always be taken to mean success. >Page 142, line 16ff. An unsigned division function analogous to >div() would be useful. This keeps getting proposed and defeated. Basically, the only reason div() etc. are defined is because we didn't want to insist that / and % work "correctly"; that's not an issue for unsigned integers. (It's also nice that both the quotient and remainder are returned simultaneously; this can be exploited by some implementations to improve efficiency in the frequent situation where both values are needed.) A lot of proposals for new features have been rejected in an attempt to keep the size of the language and its environment relatively small. (This attempt hasn't been totally successful, but it's certainly a worthwhile goal.) Therefore, please don't interpret failure to adopt a suggestion as necessarily implying that there is something wrong with the idea, although often there is (in which case the response should point out what). Reminder: Current public review period ends 07-Mar-1986. There WILL be another, 2-month, public review, since X3J11 has decided to make substantive changes to the current draft [as reported in another note].