

Is that a compiler bug? - bbatsell
http://blog.regehr.org/archives/26

======
dadkins
I was skeptical about his example of a compiler bug. Take the following
similar example:

    
    
        int bar(void) {
            unsigned x = 1;
            int y = -1;
            return x > y;
        }
    

Surprisingly, the result is always 0, at least on every version of gcc I've
tried. How could this be? It turns out unsigned's are one area where the C
standard really screwed up. When comparing a signed and an unsigned value, the
compiler helpfully promotes the signed (-1) to unsigned.

I was surprised the given example with chars instead of ints didn't give the
same result. Was it really a bug, or just ambiguity in the standard?

~~~
ori_b
> When comparing a signed and an unsigned value, the compiler helpfully
> promotes the signed (-1) to unsigned.

So what do you think the compiler should do? Convert the unsigned into a
signed? Disallow comparison/assignment/addition/... without an explicit cast?

------
patio11
Compiler bugs are like lupus. It's not lupus, either.

Relatedly, a certain outsourcing company I can't name really, really needs to
stop closing every ticket with "We investigated and it should work fine, so it
is probably a framework bug." Particularly when the code at issue looks like:

String someLabel = null; someLabel.split(","); // throws NPE. Probably
framework bug.

------
yread
Why doesn't gcc emit warning Wsign-compare for the first example? Why does it
emit it only for C++ code?

~~~
dadkins
I wondered that too. My best guess is that range of signed/unsigned char both
fit in signed ints, so there's no ambiguity in promoting them to ints.

------
Groxx
... or are you just happy to see me?

It's an interesting write-up in support of compiler-related bugs, with a
couple examples (something sorely missed in many others).

