Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: Pcc bites it (was Re: programming puzzle (silly))
Message-ID: <24878@amdcad.AMD.COM>
Date: 16 Mar 89 16:45:10 GMT
References: <28336@ucbvax.BERKELEY.EDU> <2550086@hpisod2.HP.COM>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 45
Summary:
Expires:
Sender:
Followup-To:

In article <2550086@hpisod2.HP.COM> decot@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@amd.com)