Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!unh!al710
From: al710@unh.UUCP (Anthony   Lapadula)
Newsgroups: comp.lang.c
Subject: Re: A curriosity in the C compiler...
Message-ID: <722@unh.UUCP>
Date: 31 Oct 88 00:25:53 GMT
References: <530@uvicctr.UUCP> <588@quintus.UUCP> <181@celerity.UUCP>
Organization: University of New Hampshire, Durham, NH
Lines: 32

In article <181@celerity.UUCP>, billd@celerity.UUCP (Bill Davidson) writes:
> In article <530@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes:
> >	This is a quick test of the C compiler, for implied bracketing...
> >This will determine if the expression "a = b == c" is parsed
> >as "(a = b) == c" (which is correct), or as "a = (b == c)" (which is not).
> 
> ACK!  Please refer to page 49 of K&R or any other C book which has a
> precedence table.  "a = b == c" must be parsed as "a = (b == c)" by
> laws of precedence which have been in C for a very long time.
> 
> A C programmer who does not know his precedence laws by heart had better
> use a lot of parentheses or he can expect a LOT of problems.
>
> 	--Bill Davidson

Maybe it's just me (and it probably is), but isn't
      a = (b == c)
a whole lot clearer than
      a = b == c
?  (And where the heck should that question mark go, anyway?)

It seems that the first version clearly points out that 'a' is being
used as a boolean, where the second one is more of an exercise left
for the reader.

Just trying to stir up another one of those "= looks too much like ==
to me" arguments....

/*
**      What, you wanted something funny?
**             --- Anthony Lapadula (...!unh!al710)
*/