> Well if that's the case then that's correct, fputc does operate on octets right? That is what I would think obvious here, as it's generally how char-based fu

> Well if that's the case then that's correct, fputc does operate on octets right? That is what I would think obvious here, as it's generally how char-based functions operate, and doing CHAR_BITS IO would be a complete mess for portable IO (and would introduce ambiguities due to endianness). Although technically what it says is: > The fputc() function shall write the byte specified by c (converted to an unsigned char) to the output stream pointed to by stream So if you have CHAR_BITS=16 and WORD_BIT=16 things get dicey. But indeed the easiest way to resolve the ambiguity is to assume that like everywhere else it only operates on the "minimum" char boundaries (an octet), and `int` is only used to allow or return `EOF`. This is what usually occurs in other char-based functions. Though in all honesty I don't know how a platform with CHAR_BITS=16 handles `char*` / `char[]`.