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?

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

It was really a bug, and they fixed it:

https://bugs.launchpad.net/ubuntu/hardy/+source/gcc-4.2/+bug...

short behaves the same as char. int, long and long long all implicitly cast. Very odd.

gcc v4.4.1, x86

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.

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

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.

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