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".
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.
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.
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".