Pcc bites it (was Re: programming puzzle (silly))

[Tim Olson]

In article <2550086 at hpisod2.HP.COM> decot at hpisod2.HP.COM (Dave Decot) writes:
| > Interesting -- the program *is* incorrect, because && has higher
| > precedence than *= so it is parsed as:
| > 
| > 	(n&&m) *= n--
| > 
| > which is illegal because (n&&m) is not an lvalue.
| 
| No it isn't.  It doesn't have two different valid interpretations, so it's
| not ambiguous, so the precedence rules are not applicable.  The only valid
| parsing of the expression is

Sorry -- I should have specified that I was talking about
pANS-conforming compilers.

| > Our MetaWare and Green Hills compilers catch it, but every pcc-based
| > compiler I tried compiled it with no warnings.
| 
| Your compilers are broken.

No, they are pANS-conforming.

The relevant grammar is:

	(3.3.13) logical-AND-expression:
		inclusive-OR-expression
		logical-AND-expression && inclusive-OR-expression


	(3.3.16) assignment-expression:
		conditional-expression
		unary-expression assignment-operator assignment-expression


There is no way to parse

 	n&&m *= n--

without adding parenthesis to make (n&&m) a unary-expression or (m *=
n--) an inclusive-OR-expression.


	-- Tim Olson
	Advanced Micro Devices
	(tim at amd.com)