The little bool of doom
28 points by dryya
28 points by dryya
Because of the
Fedora [is] a great place to test GCC pre-releases on a large, varied codebase.
remark at the beginning, I really hoped this article would end with something about this bug being reported to gcc and fixed... Except I've just tried this on gcc 15.2, and I still get the nonsensical output.
I wonder if they would even fix it. After all, the standard allows it! Maybe I'm just old-fashioned for expecting equality to be transitive.
After all, the standard allows it!
No, it’s undefined behaviour to memset a bool to -1.
That's what I meant. My point was that I think the compiler should still try to act somewhat reasonable when faced with UB.
But, I thought about this a bit more, and I take that back. The assumptions on the values of bools do let you generate better code, and more importantly, setting a bool to -1 is indeed a pretty silly thing to do, maybe unless you're porting legacy code (as in this case).
I saw gcc doing silly stuff on UB so I immediately complained, instead of actually thinking about the situation for a bit more :/
I expect that the memset itself isn't undefined behavior, but the attempt to observe the value afterwards is: it is an access of a trap representation not through an lvalue of character type.
Isn't initializing a bool to -1 the issue here, that the compiler should at least warn about? Assigning anything other than true or false to a bool is clearly ub.