3 ms·

The main point of contention seems to be that fputc is defined to return the value that was written to the stream. However, TI's implementation of it returns th

The main point of contention seems to be that fputc is defined to return the value that was written to the stream. However, TI's implementation of it returns the character passed in as a parameter (eg 0x1600), but actually writes (unsigned char)(0x1600 & 0xff) to the stream.

masklinn 4y ago
That doesn’t seem to be the case. The tests are strangely interleaved, but if you read carefully: - cread and cwritten are always the same, which is required by the standard - they differ from c Meaning fputc does return the value actually written, not the value input. And OP spends the entire essay freaking out about that. Well really that fputc would operate on octets when the implementation’s char is larger than that. You can see it in the second section, TFA complains that TI / DSPs return 2. Which, mind, is the entire point of fputc returning what it wrote.
- nuc1e0n 4y ago
  Ah ok. Well if that's the case then that's correct, fputc does operate on octets right? The only reason it returns an int is to distingush EOF AFAIK. To be honest I found the article hard to follow.
  - masklinn 4y ago
    > 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[]`.

masklinn 4y ago

That doesn’t seem to be the case. The tests are strangely interleaved, but if you read carefully: - cread and cwritten are always the same, which is required by the standard - they differ from c Meaning fputc does return the value actually written, not the value input. And OP spends the entire essay freaking out about that. Well really that fputc would operate on octets when the implementation’s char is larger than that. You can see it in the second section, TFA complains that TI / DSPs return 2. Which, mind, is the entire point of fputc returning what it wrote.

nuc1e0n 4y ago
Ah ok. Well if that's the case then that's correct, fputc does operate on octets right? The only reason it returns an int is to distingush EOF AFAIK. To be honest I found the article hard to follow.
- masklinn 4y ago
  > 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[]`.