Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nbires!hao!boulder!sunybcs!rutgers!ucla-cs!zen!ucbvax!decvax!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: A bug in 'lint'
Message-ID: <874@mcgill-vision.UUCP>
Date: Sat, 29-Aug-87 23:30:19 EDT
Article-I.D.: mcgill-v.874
Posted: Sat Aug 29 23:30:19 1987
Date-Received: Sat, 12-Sep-87 15:47:49 EDT
References: <273@askja.UUCP>
Organization: McGill University, Montreal
Lines: 25
Keywords: lint bug cc

In article <273@askja.UUCP>, frisk@askja.UUCP (Fridrik Skulason) writes:
> main() { int x; x=1;   x && x += 1;   return(0); }
> [ with reference to the "x && x += 1" statement ]

> The lint program is perfectly happy with it (at least on HP/UX,
> Eunice, and Altos SysV Unix).
> (And what's even worse, so is cc on Eunice and Altos SysV Unix)
> cc on HP/UX complains (correctly) (as MSC does) that "x && x" is not
> an lvalue.
> Any comments ?

4.3BSD cc accepts the above and rewrites it to x&&(x+=1) without
telling you anything about it (or at least that's what it looks like
from the assembly code produced with -S).  Just to check that it wasn't
that it had the precedence wrong (!), I tried "x+=1&&x" which it
handled correctly.

4.3BSD lint is also silent, not surprisingly.

This is BROKEN, I say BROKEN, BROKEN BROKEN BROKEN....but I don't
suppose the C support group at Berzerkeley is listening. :-(

					der Mouse

				(mouse@mcgill-vision.uucp)