The little bool of doom

28 points by dryya 19 hours ago on lobsters | 5 comments

dzwdz | 13 hours ago

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.

dzwdz | 8 hours ago

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 :/

ibookstein | 5 hours ago

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.