From:	gpt20 AT thor DOT cam DOT ac DOT uk (G.P. Tootell)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: how to interpret this...
Date:	2 Dec 1996 23:53:12 GMT
Organization:	University of Cambridge, England
Lines:	24
Sender:	gpt20 AT hammer DOT thor DOT cam DOT ac DOT uk (G.P. Tootell)
Message-ID:	<57vq58$49p@lyra.csx.cam.ac.uk>
References:	<57ve1o$rfk AT lyra DOT csx DOT cam DOT ac DOT uk> <32A36F0E DOT 463F AT cornell DOT edu>
NNTP-Posting-Host:	hammer.thor.cam.ac.uk
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

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

|> 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 -