programming puzzle (silly)

[Blair P. Houghton]

In article <24820 at amdcad.AMD.COM> tim at amd.com (Tim Olson) writes:
>In article <YY6_v5y00UkaI0ZW1_ at andrew.cmu.edu> bader+ at andrew.cmu.edu (Miles Bader) writes:
>| From klier at ucbarpa.Berkeley.EDU (Pete Klier):
>| > 
>| > main(m,n){scanf("%d",&n);for(m=n>0^n>9;n&&m*=n--;);
>| > printf(m?"Answer=%d\n":"error\n",m);}
>
>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.  Our MetaWare and
>Green Hills compilers catch it,
>What do other compilers out there do?

Depends on your attitude.

1.  The cc on the uVAXen (Ultrix) passes it unnoticed.

2.  While cc on the Encore (Umax) says
"junk.c", line 1: Operand must be an lvalue

3.  Lint always says
junk.c(8): warning: precedence confusion possible: parenthesize!

I view the uVAX as utilizing a heuristically-extended version of the
"maximal munch" rule, where the syntax has made it obvious that the
lvalue given isn't an lvalue, so it looks for the next obvious
interpretation.  Groovy.  Whatever turns you on, man.

I view the Encore as applying the tokenize-first, interpret-later
version of the "maximal munch" rule.  I'm a bit of a code-fascist
myself, so I'd go with this one.

Lint?  Well, I had to give it a "-h" in order to get it to talk.
Don't you just hate weasely informants?

				--Blair
				  "Don't you just hate computer narcs?"