The Little Bool of Doom (2025)

Excellent debugging journey.

If I were the author, I would skip the part about using the compiler explorer and reading the assembly. When I write C code, I need to satisfy the rules of the C language. Unless I’m debugging the compiler or dealing with performance issues, my experience is that reading the generated assembler and understanding it is usually a slow way of debugging. The author eventually did compile with -fsanitize=undefined but I would honestly do that first. It prints a nice error message about the exact issue as the author has shown.

> 1. Explicitly set the C standard to C17 or older, so the code is built using the custom boolean type.

> Option 1) seemed like the easiest one, but it also felt a bit like kicking the can down the road – plus, it introduced the question of which standard to use.

Arguably, that's the sanest one: you can't expect the old C code to follow the rules of the new versions of the language. In a better world, each source file would start with something like

    #pragma lang_ver stdc89

and it would automatically kick off the compatibility mode in the newer compilers, but oh well. Even modern languages such as Go miss this obvious solution.

On the topic of the article, yeah, sticking anything other than 0 or 1 into C99 bool type is UB. Use ints.

> memset (sprtemp,-1, sizeof(sprtemp));

Yikes. I think this article undersells the point somewhat. This line of code undermines the type system by spraying -1's into an array of structs, so the only surprise to me is that it took this long to break.

> For this, I used the Godbolt compiler explorer.

> Ah-ha! The generated instructions were ever so slightly different. This would be great news, if it wasn't for me forgetting about one little detail: I have zero knowledge of x86 assembly.

Lol'd at this. I've been there: "ah hah! I found you. hrm, now what does this mean..."

TFA makes me thankful my work doesn't involve C / C++. Learning it earlier in life was enough.

This brings memories - back when I was a student programming in Turbo Pascal 6, I got the same invalid bool (due to array range overflow) which was both true and false at the same time.

There's another way to explain the UB: IIRC, any value when stored to a _Bool is supposed to be converted to 0 or 1. The memset() bypasses this rule, boom.

> After consulting some sources, I started translating the assembly instructions into plain Polish

Ah yes, obfuscation

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.