--- Comment #24 from Don <> 2011-11-25 04:05:29 PST ---
It seems wrong to me that:

if (-1 < 2u) {...}
fails to compile. Both are in the range -int.max .. int.max, so they can safely
be compared using signed comparison.

The problems with mixed sign are when one operand can be in the range
-int.max..0 and the other can be in the range int.max+1u..uint.max. If at least
one of the operands is in the polysemous range, there should be no

But, the patch as it stands allows a polysemous-ranged int to be compared with
a uint, but does not allow a polysemous-range uint to be compared with an int.
At present the spec doesn't give any reason for unsigned to be treated from

The problem is the silly C promotion rule that converts both operands to
unsigned (instead, it should generate an error). In any existing C code that
works, it works because the signed operand is in the polysemous range. Of
course there could be code which relies on (-1<2u) being false. But surely such
code is broken.

Do we really need to retain backwards compatibility with broken C code?

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to