[AnimalMuppet]

To the degree that you were worried about such things, this wasn't a real answer. Yes, it saves you if you have a boolean variable... maybe?

  if (var == TRUE)
    ; // It was 7
  else if (var == FALSE)
    ; // it was zero
  else
    ??? what do I do here?

And you need to solve that "what do I do here" for every single conditional on a boolean, and have the extra lines of code to handle it and not crash.

But, you know, what if it was a variable that you used in a switch statement instead? Or just "if (i > 17)"? Bit flips can affect your logic all over the place, not just when it's a boolean variable.

And then, if a bit flip can affect a boolean, it can also affect a pointer. Or the return address on the stack (or the link to the previous stack frame).

Or it can flip a bit in the code.

So this is, at best, a very very partial solution, and it's non-trivial to implement. So this was very much not standard practice or a "convention".

[russdill]

I've been on a team trying to argue that exact thing. If you aren't going to handle the case where the var is neither true nor false, at least by explicitly documenting the fail-safe case, you're just cargo culting. You get a lot of that type of thing in MISRA and automotive codebases.

Any team that realizes that the compiler may choose to optimize out a shit-ton of such code gets an extra gold star.

[AndreiBB]

Here is how I do it:

#define FALSE 0

#define TRUE (!FALSE)

ASSERT( TRUE != FALSE );

and let the compiler worry about which bits to use for TRUE

[dahart]

Why do you think you need the “else: ??? What do I do here?” case?

Until you added the 2nd test and the 2nd else case, there is no scenario under which both paths of an if/else would fail to execute due to a bit flip of the test variable, because with ‘if (boolean_condition) {} else {}’ there is only 1 conditional test. A bit flip could have caused the wrong branch to execute, but it could not have skipped both branches. A bit flip could change the jump instruction to something else, but in that case your imagined else case still wouldn’t help.

> this is, at best, a very very partial solution

FWIW, the author said this, and fairly succinctly, saying this TRUE=7 thing is “of course foolish as such a 1 bit hardware error would "trash" pretty much any system”. He was only having a bit of fun that cost nothing, and nowhere suggested this is a solution to cosmic rays or other data errors.

[LordShredda]

if var is neither this nor that then it's not a boolean