[thecyborganizer]

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 low levels" - C treats 0==FALSE
  and !0==TRUE - most people use 0/1 ... but thats only 1 bit "difference".  I
  sometimes use 7=TRUE as thats 3 bits with no more chars to type (and of course
  foolish as such a 1 bit hardware error would "trash" pretty much any system -
  but I do tend to be a creature of habit :)

I have never heard of this convention before! Was "random bitflips messing with your conditionals" a common problem back in the day?

[kqr]

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.

[LastTrain]

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.

[jareklupinski]

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]

Except that if you have the bit endian wrong, 0xA5 is the same forward and backward.

[jareklupinski]

that's true! 0xAA 0x55 would work to differentiate that case?

[MadnessASAP]

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]

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]

0xAA 0x55 is actually used as the last two bytes in the MBR just for this purpose

[ahoka]

Endianness is byte order.

[mysterydip]

Bit endian is a thing in serial protocols. I had an issue with that when using a microcontroller to talk to an LCD last week.

[UweSchmidt]

How would a HNer who's not familiar in those nether regions of computing, but wants to feel the excitement of sending a bitstream over a (possibly faulty!) serial data line, get started? Two Arduinos and a cable maybe?

[robocat]

Personally I would recommend finding fun or useful projects where you have an outcome you really desire. Start simple - one sensor like a bath overflow warner (arduino is good or maybe raspberry pi).

Learning hardware just for the sake of it is tough to keep motivated and perhaps you would never use the skills you learn? Hardware adds a tougher level to debugging - but software experience gives you a fantastic start - a logical mind and rational drilling down.

If you can fix your car you have the skills to start on electronics!

A lot of skilled people grew up through the hardware generations e.g. I began learning basic electronics because on an Apple ][ everything was simpler and we were all at the same stage. My first job was writing low level serial driver code and regularly dealing with serial devices (e.g. on PC). Our modern context is just not the same. The internet is hard to learn from. It is difficult to write good articles to help - the experienced like me just know a huge variety of implicitly learned knowledge.

I suggest you concentrate on a useful or fun outcome - I believe it's good life practice (and good engineering) to stay focused on the outcome and not get too side-tracked by explicitly trying to learn. We implicitly learn just by doing!

[benj111]

>If you can fix your car you have the skills to start on electronics!

I'd like to think that this is a comment on the ease of fixing cars, rather than a comment about how fixing cars is basically embedded hardware/software dev....

[jareklupinski]

yup that's what I was building :)

i was sending pixel data out from an Arduino (ESP32 really but using Arduino IDE) to a bunch of shift registers that seemed to be 74x595 (but couldnt know for sure) to resurrect an LED display for a local art project, and reading the data coming back out from the last register let me know I was at least getting back what I was putting in, which helped me troubleshoot a few wire length and speed/stability issues

to get started with electronics and hardware in general, I wrote a short tutorial: https://news.ycombinator.com/item?id=35116705

[UweSchmidt]

That tutorial of yours is a lot more than I expected to get out of my question, such a cool first project! Thanks!

[Muromec]

Esp32 is the cool arduino.

[turndown]

The way that really clarified things for me was buying a 3d printer(an Ender 3 for me) and a Raspberry Pi. Setting it up and flashing a new OS to it should basically teach you the rudimentary workings of the hardware->software interface.

[olalonde]

I would suggest to search for "Arduino starter kit" or "embedded starter kit" on Amazon. They come with lots of components and usually with some project guides.

[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

[layer8]

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]

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]

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.

[dboreham]

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.

[ziddoap]

>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?).

[ChrisSD]

1993

[bernds74]

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.

[indymike]

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.

[anonymousiam]

SEE/SEU are not a relatively new thing. However, the frequency of events is inversely proportional to the feature size, which has been decreasing over time.

https://en.wikipedia.org/wiki/Single-event_upset

https://en.wikipedia.org/wiki/Die_shrink

[dragonwriter]

> Random bitflips (aka hardware that doesn't work) are a relatively new thing.

I thought they (from cosmic rays, etc.) were always a thing, but so rare that you needed a very large system (in scope or time or both) to have a substantial chance of encountering one (outside of noisy comm channels, which use error correction protocols for exactly that reason.)

[defrost]

Some event (unknown) triggered multiple spikes in the "tell me three times" redundant three ADIRU units of Qantas Flight 72 causing a WTF unscheduled sudden and dramatic pitch down

https://en.wikipedia.org/wiki/Qantas_Flight_72#Conclusion

Cosmic rays were suspected but unconfirmed (kind of hard to confirm after the fact).

"All the aircaft in the world" for sixty years is kind of a large system given that currently there are on the order of one million people in the air at any moment.

[heisenbit]

There are lot‘s of thing that can go wrong beyond cosmic rays. Like timing on the bus or signals from close wires. Digital is an abstraction of an analog and chaotic reality.

[justin66]

> Random bitflips (aka hardware that doesn't work) are a relatively new thing.

Bits flipping due to hardware that didn’t work well was what caused Xerox PARC to implement an error correcting memory for MAXC, fifty years ago.

https://gunkies.org/wiki/Maxc

> Bit flips due to buggy software was a thing though.

No kidding.

[dvaletin]

What you mean by relatively new? I observed bitflips a couple decades ago, causing machine to panic.

[fuzztester]

Panics and consequent crashes or reboots (?) used to happen in Unixen at times, maybe due to bitflips or other hardware errors.

[euroderf]

Cosmic rays ?

[wrs]

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]

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/langua...

[bilekas]

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]

In the long-ago world where integers were commonly used as arrays of bit flags, it made perfect sense that True = Not False.

[layer8]

The OP still wanted to only type a single character.

[egometry]

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]

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.

[Supermancho]

> 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#R...

[vitus]

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.

[buildbot]

I swear there was a google paper about using a DC as a really bad particle detector, but I can’t find :/

[scottlamb]

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

[rendaw]

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]

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.

[kortilla]

It’s a problem even now if you have software security checks dealing with adversarial actors with hardware access.

[benj111]

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]

That depends on

a) Two's complement representation

and

b) Wraparound on arithmetic, which is still UB in low-level languages.

[benj111]

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.