From:	"A. Sinan Unur" <asu1 AT cornell DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: how to interpret this...
Date:	5 Dec 1996 16:49:06 GMT
Organization:	Cornell University
Lines:	34
Sender:	asu1 AT cornell DOT edu (Verified)
Message-ID:	<586ue2$7st@newsstand.cit.cornell.edu>
References:	<57ve1o$rfk AT lyra DOT csx DOT cam DOT ac DOT uk> <32A36F0E DOT 463F AT cornell DOT edu> <57vq58$49p AT lyra DOT csx DOT cam DOT ac DOT uk>
NNTP-Posting-Host:	128
Mime-Version:	1.0
To:	gpt20 AT thor DOT cam DOT ac DOT uk
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

gpt20 AT thor DOT cam DOT ac DOT uk (G.P. Tootell) wrote:
>is the ambiguity not worthy of some warning then? particularly under -wall?
>i spent ages tracking this bug down :(
>your theory may be right actually, i was able to determine that the behavior was
>wrong but that the c==0 part worked, so your analysis may well be correct.
>
>nik

if you have the time, try compiling the same code with -W in addition to 
-Wall. see if that warns you. for more info, check out the gcc section in 
the info documents. (gcc, invoking, warning options, towards the end).

sinan.

>
>|> ok, i'll give this a try but i may be totally wrong.
>|> 
>|> here is what seems like a logical explanation to me. assume that the
>|> compiler, when processing your code, uses a 'maximal munch' rule, i.e.,
>|> it always considers the longest possible character sequence that is
>|> meaningful in the context. so, now suppose the compiler is at the
>|> beginning of a==b==c==0. what is the maximal meaningful substring? it is
>|> a==b. what is the next one. it seems to be that's ==. what is the one
>|> after that? well, c==0. so, a==b==c==0 gets interpreted as 
>|> (a==b) == (c==0) (which is not (a==b) && (c==0).)
>|> 
>|> this seems like a logical explanation to me. however, i won't be able to
>|> test it for a couple of days. sorry for the unsubstantiated claims.
>|> 
>|> sinan.
>
>-- 

- Raw text -