5 ms·

From STYLE.TXT: - True=7 - Having lots of very low-level code and hardware experience, I developed a bit of tendancy to "minimize what can go wrong at l

• wrs 3y ago
  I’ve been involved with systems where 0xffff… was canonical “true”, but not something as specific as 7! If you’re going to turn on more bits, why not all of them? Though I think this was because the NOT instruction was used for logical inversion, so the bit flip theory doesn’t apply.
  • cpeterso 3y ago
    For example, the value of Visual Basic's "True" keyword is -1. This seems silly from the perspective of a C programmer, but -1 (0xffffffff) is "more true" than 1 because every bit is true, not just the LSB. :) https://learn.microsoft.com/en-us/dotnet/visual-basic/language-reference/data-types/boolean-data-type https://learn.microsoft.com/en-us/dotnet/visual-basic/langua...
    • bilekas 3y ago
      Even in VB there is a grain of rationale .. I never even considered before WHY it was -1.. I always just thought it was VB doing VB, but now I have gained +1 respect for Vb.. Edit: "Gained" no "Earned"
    • marssaxman 3y ago
      In the long-ago world where integers were commonly used as arrays of bit flags, it made perfect sense that True = Not False.
  • layer8 3y ago
    The OP still wanted to only type a single character.
• jareklupinski 3y ago
  tangential to 'how can a bit be wrong', when trying to see if a serial data line is working, i write 0xA5 ( 1010 0101 ) to send an alternating bitstream with a twist so i can test the greatest number of things i think can be wrong at once
  • genter 3y ago
    Except that if you have the bit endian wrong, 0xA5 is the same forward and backward.
    • jareklupinski 3y ago
      that's true! 0xAA 0x55 would work to differentiate that case?
      • MadnessASAP 3y ago
        Yes, AA and 55 are common test patterns for a variety of hardware. Haven't seen A5 in the wild but I suppose it could be useful as a initial "Let's setup a connection" where endianness is unknown. Assuming the next thing that is exchanged is an endian negotiation.
      • genter 3y ago
        I like to have several sequential ones. Easier to see on the oscilloscope. (I spent last night getting a microcontroller to talk to a SPI device, so I'm still licking my wounds.)
      • theblazehen 3y ago
        0xAA 0x55 is actually used as the last two bytes in the MBR just for this purpose
    • ahoka 3y ago
      Endianness is byte order.
      • 3y ago
• dboreham 3y ago
  No. Random bitflips (aka hardware that doesn't work) are a relatively new thing. Bit flips due to buggy software was a thing though. This is why most database engines checksum the payload data even in memory. I've also seen network packets corrupted because a bridge (former name for switch) trashed data in flight, then reconstructed its CRC for the corrupt data on the onward leg.
  • indymike 3y ago
    Bitflips aren’t a new thing. I’ve been rarely but painfully bit by them since at least 1986. This. Excludes serial and modem communications where it was a way of life.
  • dvaletin 3y ago
    What you mean by relatively new? I observed bitflips a couple decades ago, causing machine to panic.
    • fuzztester 3y ago
      Panics and consequent crashes or reboots (?) used to happen in Unixen at times, maybe due to bitflips or other hardware errors.
  • bernds74 3y ago
    I beg to differ. Early 90s there were some Amiga memory expansions that would constantly flip bits. I'm pretty sure it contributed to the sentiment that the system wasn't the most stable, although I'm pretty sure one or two of my friends with PCs saw similar issues on their machines. Maybe Microsoft Word wasn't to blame for all the crashes? Of course, trying to work around it in software is utterly futile.
  • ziddoap 3y ago
    >Random bitflips (aka hardware that doesn't work) are a relatively new thing This implies that old hardware always worked, which I strongly doubt (what year did hardware go from always working to not?).
• egometry 3y ago
  Still is. And there's little to be done about it. Unless you can stop cosmic rays. Luckily it doesn't happen THAT often. I forget the exact metric but I recall various Google Engineers saying that something like one out of a million test run failures is a random bitflip?
  • eichin 3y ago
    Cosmic rays were a theory in 70's era hardware for failures that ended up being proven to be particles emitted by the ceramic packaging itself. (Modern bitflips are have more to do with component sizes several orders of magnitude smaller.) (edit: not saying that cosmic rays aren't a problem now, just that they only became a problem as chip element sizes shrunk, and they're probably not the only source.) Also, you can definitely stop cosmic rays, that was part of how they eliminated them as the source.
    • buildbot 3y ago
      I swear there was a google paper about using a DC as a really bad particle detector, but I can’t find :/
    • Supermancho 3y ago
      > Also, you can definitely stop cosmic rays As I understand it, bit flipping in RAM is mitigated by error correction, via auxilliary and redundant bits. https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Row_and_column_redundancy https://en.wikipedia.org/wiki/Dynamic_random-access_memory#R...
      • vitus 3y ago
        ECC RAM is for the most part relegated to server-grade components, for what it's worth. So your phone, your laptop, your router? Almost certainly not using any ECC RAM, unless you've gone out of your way to do so.
• scottlamb 3y ago
  > I have never heard of this convention before! Was "random bitflips messing with your conditionals" a common problem back in the day? Due to RAM/CPU failures? I don't think so (though I have seen it, fwiw). With weird serial protocols that don't have proper checksums/digests, running over sketchy wiring? Yeah, and that might be part of "very low-level code and hardware experience".
• layer8 3y ago
  No, this is more a case of “this could conceivably happen, so why not guard against it where it’s easy to do”. Though personally I would have used -1.
  • adrianmsmith 3y ago
    The BBC micro and Archimedes used -1 as true in BASIC. It meant that you didn't need the distinction of "logical operators" (like && in C) and "bitwise operators" (like & in C). You could just use bitwise operators, e.g. the bitwise NOT operator would convert 0 (all bits clear) was -1 (all bits set) so there was no need for "logical operators". I always felt that was more elegant than C (but of course required a two's compliment machine, which BBC/Archimedes was, but C didn't require).
    • layer8 3y ago
      This is only sound if you have a boolean type that guarantees that the bits are either all zero or all one. Once a mix of bit values is possible, you have to define whether it mean true or false, and then you can’t use the bitwise operators anymore.
• AnimalMuppet 3y ago
  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".
  • LordShredda 3y ago
    if var is neither this nor that then it's not a boolean
  • AndreiBB 3y ago
    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
  • russdill 3y ago
    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.
  • dahart 3y ago
    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.
• LastTrain 3y ago
  No, and the author basically admitted it was silly. My counter would be that it makes the intent less clear. I loved reading through his style doc though and I love that he just threw all this stuff out there. Something in his collection is bound to scratch somebody’s itch.
• kortilla 3y ago
  It’s a problem even now if you have software security checks dealing with adversarial actors with hardware access.
• rendaw 3y ago
  This doesn't make any sense even if the system isn't trashed. If 7 == true and anything other than 7 == false, then one bitflip will still change the meaning. If 7 == true and 0 == false, then you could have code that does `if (mybool == 7) { ... }` and later `if (mybool == 0) { ... }` and end up with a situation where code path invariants are broken (i.e. mybool is neither true nor false. If you use `>= 7` to mean true and `< 7` to mean false, while a 0 false value won't randomly become true if one of 3 bits randomly flips, a `7` true value will become false if any of those bits flip. And if any of the other bits flip, 0 will become > 7.
  • fabbari 3y ago
    In C any value != 0 is considered true. Nothing special about 7, he could have used any other number, but 7 is a single character, so he used that.
• kqr 3y ago
  Even if it was, are you really going to think of every conditional as a tri-state boolean? Or will you assume that one of the branches is safe to execute during failure? Or will you count the number of bits in each conditional and assume more ones than zeroes is a true, with no error correction? Will you log that a bit has flipped or otherwise alert the operator? Will you consider that as evidence that an int has changed value too? Will you store ints with three bits per bits also? Error detecting codes have their place, but it takes more than just saying that true is 7.
• benj111 3y ago
  Slightly off topic, but why did 1 become the truthy value and not -1? Logical nots would then work. And youre still an inc/Dec away from the opposite.
  • never_inline 3y ago
    That depends on a) Two's complement representation and b) Wraparound on arithmetic, which is still UB in low-level languages.
    • benj111 3y ago
      Ok. I used -1 as a short hand for 0b11111111(11111111(1111111111111111(11111111111111111111111111111111)))) Not doesn't rely on wrap around arithmetic. Wrap around arithmetic is only undefined for signed values. What platform doesn't wrap around signed integers? Just because c has some undefined behaviour, doesn't make it some natural law of the universe.