Path: utzoo!attcan!uunet!husc6!bu-cs!buengc!bph From: bph@buengc.BU.EDU (Blair P. Houghton) Newsgroups: comp.lang.c Subject: Re: programming puzzle (silly) Message-ID: <2273@buengc.BU.EDU> Date: 12 Mar 89 07:09:07 GMT References: <28336@ucbvax.BERKELEY.EDU> <2821@goofy.megatest.UUCP> <24820@amdcad.AMD.COM> Reply-To: bph@buengc.bu.edu (Blair P. Houghton) Organization: Boston Univ. Col. of Eng. Lines: 38 In article <24820@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: >In article bader+@andrew.cmu.edu (Miles Bader) writes: >| From klier@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?"