mod.std.c Digest V5#1

[osd7 at homxa.UUCP]

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 at 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 at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.