> (The latter actually seems like it makes a tiny bit of sense on a system that doesn’t have 8-but hardware types at all.) > But this is all pretty ridiculous,

> (The latter actually seems like it makes a tiny bit of sense on a system that doesn’t have 8-but hardware types at all.) > But this is all pretty ridiculous, and none of the choices are really good. I can understand having bona fide 16-bit characters, but having this mismatch is nasty. I’d say the latter (and the behaviour observed by TFA) is the only sensible behaviour, otherwise it's plain not possible to do IO portably, instead you would have to write different codepaths based on CHAR_BIT. Not only that but: > Do I get a four-byte file containing 0xb, 0, 0xa, 0? Do I get a two-byte file? There's actually a third choice because multibyte IO means endianness becomes a factor. So given char[]{0xab, 0xab} the output of writing memory contents literally with CHAR_BIT=16 could be 0x00 0xAB 0x00 0xAB or 0xAB 0x00 0xAB 0x00