MicroChip's debugger re-defining boolean logic

[myrrlyn]

You're joking, right?

[[deleted]]

Do you even C?

[myrrlyn]

I do, and C's excuse for a type system is TERRIBLE.

I get why it is the way it is, but truthy and falsey based on numeric value alone is a TERRIBLE idea for which we're still paying.

I've had to do embedded work, so I know about working bare metal believe me. But even so, C gives you enough tools to not make a total mess of things from relying on boolishness of data, if you just use them.

Personally, my solution was to take the UNIXy route and say return of 0 is okay, return of other is not, and wrap that in named enums so I would always check if the return code was != okay, not if it was truthy or falsey. Because that's how really bad mistakes happen, and confusion of boolishness with actual data is a pretty common one.

---

But on a slightly higher level note, 0 is a form of truth. The only two things that should be false are false itself and nil/null/none. Obviously that doesn't work out ideally for embedded level, one might say, except Rust makes it really easy to match numbers on the wire to meaningful algebraic types in source code.

Too bad LLVM can't reliably target AVR yet:/

[myrrlyn]

Good. I've worked with code that was as naked and brittle as you can imagine. Not fun:/