precedence of ?: (was: precedence of && (was: precedence of ?:))

[T. William Wells]

In article <2550103 at hpisod2.HP.COM> decot at hpisod2.HP.COM (Dave Decot) writes:
: > I don't find the grammar especially "convoluted"; in fact it's
: > relatively straightforward.  The reason for the several types of
: > expression is precisely to reflect the correct precedence without
: > requiring precedence to be provided by means outside the grammar.
:
: Note that it also renders invalid several classes of expression that
: were completely correct in K&R I.  The changes to the grammar require
: conforming compilers to reject (or at least warn about) such expressions,
: because they are now syntax errors.  For instance, consider:
:
:     double five, three;
:
:       five = 2.0 +  three = 3.0;
:
: Although I grant that it seems ambiguous, it has two valid parses according
: to K&R I's grammar (ignoring its precedence rules, for the moment):

But you *can't* ignore the precedence rules.

:     (five = 2.0) + (three = 3.0);     /* somewhat silly */
:  or
:     (five = (2.0 + (three = 3.0)));   /* more likely what was intended */
:
: The second of these above is the correct interpretation when using the
: precedence rules to resolve ambiguity (the only moral use of precedence
: rules as far as I'm concerned).

No it is not the correct interpretation. The precedence rules state
that addition is done before assignment. They do *not* state that
addition is done before assignment when there are two ways of
interpreting the expression. PARSING IS (with one exception) DONE
INDEPENDENTLY OF SEMANTIC ANALYSIS. (The exception? Type names must
be distinguished from other identifiers or the language is ambiguous.)
Thus the precedence rules say that the correct parse is:

	five = (2.0 +  three) = 3.0;

This will, of course, fail due to the semantic error. And we'll note
that existing compilers will flag the original as an error.

: Another interesting effect of the Standard's grammar is that:
:
:     k = (!y ? 0 : t = 1);
:
: is valid, but

No it is not. t = 1 is not a conditional-expression.

:     k = (y ? t = 1 : 0);
:
: is a syntax error, although it had a single unambiguous parse in K&R I.

Wrong again. It is frequently done incorrectly by K&R compilers,
precisely because precedence is not a good way to specify ?:. And,
since t = 1 *is* an expression, Standard C will permit it.

: The kinds of valid expression are different for the two right-hand
: operands of the ?: operator.

That is correct. The middle expression is any arbitrary expression;
the rightmost is a conditional-expression, which means that it can't
contain an unparenthesised assignment or comma operator.

BTW, the left operand is slightly more restricted: not only can it
not contain the assignment or comma, it can't contain ?:.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill at twwells.com