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

[Dave Jones]

>From article <2550086 at hpisod2.HP.COM>, by decot at hpisod2.HP.COM (Dave Decot):
  From some article, by somebody (??):
>> 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
> 
>     n && (m *= n--).
> 

Two can play this "No it isn't" game.

I'm sure lots of others will correct you on this, but just in case...

A compiler which allows the above statement is broken, in as much
as it will compile nonportable programs without warning. The fact that
the statement is semanticly meaningless when parsed occording to the
precedence rules is not a legal reason for parsing it some other way.

The precedence rules, as defined in K&R, and the ANSII draft standard,
and as implemented in conforming compilers, are purely syntactic.
The part of the compiler which determines precedence, (called the "parser"),
does not refer to the semantic values assigned to identifiers, except in
the case of identifiers which have attained type-name status through the
typedef mechanism.

Many languages are completely context-insensitive when parsing.  In Pascal,
for example, if you write this:

   if (int1 + int2 > 0 or boolvar ) then foo;

It will tell you there is an error.

The only meaningful way to parse it is like this:

   ((int1 + int2) > 0) or boolvar


But because ">" is (incredibly) defined to have higher precedence
than "+", it parses it like this:


    (int1 + (int2>0)) or boolvar

When it gets to the semantic analysis phase, the compiler will complain
of type-mismatches.