[lowbloodsugar]

That is a fucking travesty. If there’s one thing we should be able to rely on C for it’s that it works with assembly, and it’s always been the case that 0 is false and any other value is true. That’s a compiler bug as far as I’m concerned. I don’t use C++ because it’s gone in a ludicrous unhelpful direction since 2000 or so, but it’s sad to learn that C of all languages decided to favor pedantry over working code.

[munchler]

The code in question is:

    if (sprtemp[frame].rotate == false)

Note that this is explicitly comparing two values, which is very different from checking whether a single value is true. Surely you wouldn't expect -1 == 0 to evaluate to true.

[robinsonb5]

> Surely you wouldn't expect -1 == 0 to evaluate to true.

I wouldn't, no - but that's exactly what's happening in the test case.

Likewise, I wouldn't expect -1 == 1 to evaluate to true, but here we are.

The strict semantics of the new bool type may very well be "correct", and the reversed-test logic used by the compiler is certainly understandable and defensible - but given the long-established practice with integer types - i.e "if(some_var) {...}" and "if(!some_var) {...}" - that non-zero is "true" and zero is "false", it's a shame that the new type is inconsistent with that.

[lowbloodsugar]

>Surely you wouldn't expect -1 == 0 to evaluate to true.

No, but that's not what happened. What happened was that 255 == 0 was true. That's a bug.

[inglor_cz]

I still remember one of my first teachers of programming softly shaming me for writing a condition like

if (something == true)

I haven't done so ever since (1997), and thus I avoid the contrary (with == false) as well, using ! instead. But I would be a lot less ashamed if I knew that there are such conditions in production software.

I would also never guess that the problem described in the article may occur...

[_0ffh]

Buy your teacher a drink! I went into university with the baggage of ten years of programming experience, mentored by my industry-experienced father. One of our profs had the exact reverse point of view (i.e. "foo == true" was according to him "good practice"), and I wisely chose to disregard his opinions on coding practices from that point on.

[direwolf20]

You're not wrong. The processor has a perfectly good zero/notzero check. There was absolutely no reason for the compiler to check if x^1==0.

[jabl]

The (minor, but still) optimization that is enabled by assuming _Bool can contain only 1 or 0 is that negating a boolean value can be with x^1, without requiring a conditional.

That being said, for just testing the value, using the zero/nonzero test that every (?) cpu has is enough; I'm not sure what is achieved here with this more complex test.