Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Clarifications on ANSI C nits Message-ID: <6921@brl-smoke.ARPA> Date: 6 Jan 88 00:12:58 GMT References: <3725@hoptoad.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 86 In article <3725@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > * I've heard a rumor that in newer drafts, hex escape sequences inside > strings are no longer limited to 3 characters, e.g. "abc\x00345" >produces "abcE" since 'E' (0x45) is (char)0x00345. This strikes me as odd. Yes, hex escapes are arbitrarily long now. I initiated the action that ended up with this, although it's not what I originally proposed. The problem was that a 3-character limit is not enough for implementations with char sizes > 12 bits. I proposed that the implementation define what the limit is, but the committee preferred to remove the limit (for hex escapes only; it's too late to change octals). \x00345 is no weirder than \x345 on an 8-bit machine. The problem of wanting to follow a hex sequence with a digit character can be solved by using string concatenation: "\x003""45". > * Is a "const void *" a void pointer? Is a "volatile void *"? Howabout >a "const volatile void *"? Howabout a "void *const"? A "pointer to void" >gets special treatment in a few places (e.g. in assignment) but it's not >clear whether these are "pointers to void". I think they're all just "void pointers". I didn't find any special meaning specified for qualified void pointer types. > * It appears from the text in section 3.5.3.3 that variable-argument-list >functions can ONLY be defined in the > foo(int c, float bar, ...) >syntax, and not in the > foo(c, bar, ...) > int c; > float bar; >syntax. GCC implements it this way. However, this makes it impossible >to support since no existing code uses the new declaration >method. It also seems to be a silly inconsistency. Yes, the ", ..." is not existing practice. Existing practice (non- prototype declarations) was retained simply to "grandfather" in existing code, but it has been flagged "obsolescent" to permit its removal in some future revision of the standard. There was little sentiment for propping up the obsolescent syntax by adding ", ..." to it. If you have to add the variadic indicator ", ..." to a declaration, you might as well convert it to prototype form at the same time. > * Though a union can now be initialized, you can only initialize one >member, but you have to surround it with { } anyway. To correctly >initialize the structure below, ALL the braces used are required: ... Logically, it could have been made more convenient for unions, but it apparently didn't occur to anyone to do so. > Furthermore, >the standard does not allow extra braces (e.g. around 2 and 4, or around the >whole thing), so you have to get it exactly right. Is this what was intended? I think extra {} are allowed by the grammar. There was some small change made to the bracketing wording at the December meeting, but I don't recall what it was. (It seemed correct at the time, so I quit worrying about it.) > * When calling a function, side effects caused by evaluating the arguments >must be complete before the call takes place. What about side effects >caused by evaluating the function name? Ron Light gave this example: ... Using a pointer to a function does not constitute evaluating the function name. Quoting the latest draft: "The order of evaluation of the function designator [postfix-expression], the arguments, and subexpressions within the arguments is unspecified, but there is a sequence point before the actual call." I added the [] remark for clarity. It seems simple enough to me: because of the sequence point, the increment must occur before the actual call. >If I reference "pc" from inside a function called from the forloop, is >its value guaranteed to be incremented, to not be incremented, or not >guaranteed? Guaranteed to be incremented. > * Are null statements (extra semicolons) allowed between declarations? >Between struct/union members' declarations? I don't see how it can be; a null statement is an expression-statement, which involves "evaluation". P.S. Of course, the above are merely my own opinions. Send in comments to X3J11 during the next formal public review if you remain unsatisfied about any of these issues.