osd7@homxa.UUCP (04/04/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c> mod.std.c Digest Thu, 4 Apr 85 Volume 5 : Issue 1 Today's Topics: Comments on Standard, section C.2 and C.3 ---------------------------------------------------------------------- Date: Thu, 28 Mar 85 15:29:12 PST From: ucbvax!ucsfcgl!arnold (Ken Arnold) Subject: Comments on Standard, section C.2 and C.3 To: cbosgd!std-c@BERKELEY [ The references below apply to the 11/84 draft. -Mod-] Well, you asked for new topics. Here is my next installment. *Problem: Unclear *Reference: C.2.1.2 Signed and unsigned integers (p. 23) *Description: When a signed integer is combined with or assigned to an unsigned integer of equal or grater length, the signed integer is converted to unsigned and the result is unsigned. If the value of the signed integer is negative, the conversion involves adding to it the largest number that can be represented in the unsigned integer type plus one." Note: In a two's-complement representation, there is no actual change in the bit pattern except filling the high-order bits with copies of the sign bit if the unsigned integer is wider. The first part of this is extremely hard to understand. The judicious insertion of commas, although they do not add information, helps to break it up into digestible parts. However, it remains unclear. I admit to not being an expert on integer representations outside of one- and two's-complement machines, but I think the following wording is both correct and clearer. If it is not, please at least follow my suggestion of adding some commas between phrases When a signed integer is combined with, or assigned to, an unsigned integer of equal length, the result is an unsigned integer. If the signed integer is of shorter length, its sign is extended before the conversion to an unsigned integer. *Problem: Unjustified extension *Reference: C.3.3.3 Unary arithmetic operators; Semantics (p. 31) *Description: The result of the unary '+' operator is the value of its operand. The operand must have arithmetic type. The integral widening conversion is performed. The expression '+E' is equivalent to '(0+E)'. Why is this added? I can guess: it is a matter of consistency and completeness. I will buy this argument if and only if the committee adopts the '^^' (logical xor) operator, whose justification is identical, and which is at least Useful. I have occasionally had to code around the lack of '^^', but have never even noticed the lack of unary '+'. See also, below, my '^^" implementation. *Problem: Unclear (only in light of current implementation) *Reference: C.3.5 Multiplicative operators; Semantics (p. 32) *Description: The result of the '%' operator is the remainder from the division of the first operand by the second. In 4.2bsd's pcc, and I would guess many others, the operands of '%' can not be floating point. Is this true in the new standard, or is the standard, by not saying otherwise, explicitly allowing '%' of reals? I hope it is the latter, but I thought I'd ask. *Problem: Suggested extension *Reference: C.3.14 (p. 36) *Description: We should add the '^^', logical exclusive-or, operator if we care about consistency. (If we don't, we have no excuse for unary '+'; see above). I suggest simply an addition between C.3.14 and the current C.3.15 (which would obviously become C.3.16) thusly: Syntax: logical-XOR-expression logical-XOR-expression ^^ logical-OR-expression Constraints: Each of the operands must have scalar type Semantics: The '^^' operator must yield 0 of both of its operands evaluate to non-zero, or both of its operands evaluate to 0. Otherwise it must yield 1. The result has type 'int'. The '^^' operator guarantees left-to-right evaluation of its operands, and guarantees that both of its operands are evaluated. *Problem: Breaks Code *Reference: C.3.15 Condition operator; Syntax (p. 36) *Description: "conditional-expression: logical-OR-expression logical-OR-expression ? logical-OR-expression : conditional-expression" This description of syntax, unfortunately, does not allow the quite reasonable expressions a ? b ? c : d : e which is unambiguously equivalent to a ? (b ? c : d) : e respectively. It insists that any non-parenthesized conditional expression be on the right-hand side of the ':', which is a new restriction, and hence can break existing code. A fix for this has been posted. Since there has been a new version of the standard, this may already have been fixed, but if it hasn't been, it should be. Ken Arnold ------------------------------ End of mod.std.c Digest - Thu, 4 Apr 85 07:59:07 EST ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above.