> This would utterly break the expectations of anyone coming from another platform, Which platform? I come from x86, ppc, mips, and arm, and in all these plat

> This would utterly break the expectations of anyone coming from another platform, Which platform? I come from x86, ppc, mips, and arm, and in all these platforms "bool's true" are sometimes ~0 and sometimes 1. For example, all SIMD operations on all these ISAs use ~0 for true, and I've fixed hundreds of bugs where people expected true to be represented by 1. Even RISC-V Vector ISA uses `~0` for true. So if anything, what would be completely retarded is for a new ISA to sometimes use 1 for true, and sometimes use ~0. That's super confusing, and people get hit by it all the time. Beyond the confusion of using different values for different operations, even for simple scalar code, it means that you can't just "logical and" with true to mask all bits, which is a super useful thing to do (so useful, that this is why all SIMD ISAs use ~0, and why 1 for true wouldn't be an option for SIMD). > (Whether that C code was allowed to make that assumption or not, it did.) Citation needed. In C, using an integer in a logical operation returns false if the integer is 0, and true otherwise. Avoiding this is _super hard_, so I doubt your claim that C code is relying on this. Also using 0 or 1 when converting to bool is handled by the compiler, and required to convert to the false and true representations of bool, where multiple true representations are allowed. If you are serializing or deserializing raw bools, most code doing this serializes 1 bit per bool. Code serializing 4 bytes, is mostly using integer types, and when reading those testing against 0 is the most common thing to do. And well code doing this needs to deal with endianness and what not anyways.