3 ms·
If by "bit-level issues" you mean bit flips (which you should be worried about), a string doesn't help much - "4" is 0x34 ASCII/UTF-8, flip lowest bit and you g
by alexvitkov 3y ago
If by "bit-level issues" you mean bit flips (which you should be worried about), a string doesn't help much - "4" is 0x34 ASCII/UTF-8, flip lowest bit and you get "5" (0x35).
I'd imagine if I have to protect against bit-level fuckery something like this would be a better representation:
struct Dough {
u64 amount;
u64 amount_again;
u64 amount_just_to_be_really_sure;
}
that and hardware-level protection of course
- rvnx 3y agoStoring the same element the same way isn't really helping against implementation bugs, if going that route, better store in multiple formats (u64, int, or string), to protect yourself from a CPU or interpreter or library bug. In practice, just store the amounts as integer, and if you are really worried, add a checksum (if total balance is not enough).
- DamonHD 3y agoThat pretty much guarantees being the victim of multiple coding bugs...
- alexvitkov 3y agoMaybe, if you're an incredibly bad programmer. Add operator overloading and method to extract the number and you never have look at the internals again.
- GTP 3y agoI think what OP's talking about aren't sw bugs, but rather hw errors like a bit flip caused by an external interference.
- marcosdumay 3y agoThat's the kind of thing for what error correction codes were invented.
- Izkata 3y agoThey're talking about floating point precision issues, same thing as the article, and explaining another way to deal with it that doesn't require thinking as low-level as bits like the article is mainly talking about.