I’ve never had the displeasure of programming on one of these large-char systems, but; > The fwrite() function shall write, from the array pointed to by ptr, u

I’ve never had the displeasure of programming on one of these large-char systems, but; > The fwrite() function shall write, from the array pointed to by ptr, up to nitems elements whose size is specified by size, to the stream pointed to by stream. So I guess fwrite writes nitems * size things of whatever size fputc writes. So, if fputc truncates, how large is the resulting file? Specifically, if I write ten chats (e.g. “Mic check\n”), do I get a ten-chat file? A ten-byte file? If I have two-byte chars and I write: {0xab, 0xab} Do I get a four-byte file containing 0xb, 0, 0xa, 0? Do I get a two-byte file? Does every file on the entire system consist of 50% zeros? Or do I end up with 0xb, 0xa, so the file is two bytes, filesystems have one-byte characters, but C’s CHAR_BIT is nonetheless 16? (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. To be clear, basically everything on old embedded designs is nasty. I have used some of these compilers, and they were unbelievably buggy messes.