3 ms·

I’m a bit surprised that this needed an entire essay when the first section title (“no”) seems rather obvious? It feels a bit like when ddevault got pissy abou

I’m a bit surprised that this needed an entire essay when the first section title (“no”) seems rather obvious? It feels a bit like when ddevault got pissy about “int” not meaning “codepoint”, when the minimum size of int is 16 bits (though in that case what they were doing was literally listed as UB in the docs).

pdw 4y ago
I don't feel it's obvious at all. Is it not surprising that you can't reliably store chars to a file using fgetc/fputc? OTOH I'm not surprised at all that embedded compilers play fast and loose with the standard.
- rsaxvc 4y ago
  > Is it not surprising that you can't reliably store chars to a file using fgetc/fputc? It was surprising until I needed I/O between two systems with different CHAR_BITs to work. Many systems need to access octet based field and communicate over octet based busses, and CHAR_BIT>8 machines are rare. If the entire char is serialized, interoperability becomes a much larger mess.
- masklinn 4y ago
  > I don't feel it's obvious at all. Is it not surprising that you can't reliably store chars to a file using fgetc/fputc? Chars 2 to 4 times larger than what the standard requires? Not really. It means one platform would be reading / writing 4 bytes (octets) at a time, at which point endianness rears its ugly head. That sounds a lot worse than clamping values to a byte.
- pantalaimon 4y ago
  I understand the reasoning. If you have a string each letter is an individual character. You wouldn't pack two ASCII letters into a a char just because your char is 16 bit. On such a platform, if you have the string "Hello" and would write the chars un-truncated you'd end up with "H\0e\0l\0l\0o\0" in the file. However, if you are not writing a string, but binary data, this would mean you now loose every 2nd 8-bit byte.
  - theamk 4y ago
    If you are writing binary data from memory, _and_ want to make sure any system can read it no matter what endianness it uses, you might need something like this: buf[0] = (data >> 24) & 0xFF; buf[1] = (data >> 16) & 0xFF; buf[2] = (data >> 8) & 0xFF; buf[3] = data & 0xFF; and if you want this code to work on all systems (including wide-char ones), you need to make sure fwrite truncates too.
pwdisswordfish9 4y ago
Where is the ddevault bit?
- jzm2k 4y ago
  Probably this one: https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html

pdw 4y ago

I don't feel it's obvious at all. Is it not surprising that you can't reliably store chars to a file using fgetc/fputc? OTOH I'm not surprised at all that embedded compilers play fast and loose with the standard.

rsaxvc 4y ago
> Is it not surprising that you can't reliably store chars to a file using fgetc/fputc? It was surprising until I needed I/O between two systems with different CHAR_BITs to work. Many systems need to access octet based field and communicate over octet based busses, and CHAR_BIT>8 machines are rare. If the entire char is serialized, interoperability becomes a much larger mess.
masklinn 4y ago
> I don't feel it's obvious at all. Is it not surprising that you can't reliably store chars to a file using fgetc/fputc? Chars 2 to 4 times larger than what the standard requires? Not really. It means one platform would be reading / writing 4 bytes (octets) at a time, at which point endianness rears its ugly head. That sounds a lot worse than clamping values to a byte.
pantalaimon 4y ago
I understand the reasoning. If you have a string each letter is an individual character. You wouldn't pack two ASCII letters into a a char just because your char is 16 bit. On such a platform, if you have the string "Hello" and would write the chars un-truncated you'd end up with "H\0e\0l\0l\0o\0" in the file. However, if you are not writing a string, but binary data, this would mean you now loose every 2nd 8-bit byte.
- theamk 4y ago
  If you are writing binary data from memory, _and_ want to make sure any system can read it no matter what endianness it uses, you might need something like this: buf[0] = (data >> 24) & 0xFF; buf[1] = (data >> 16) & 0xFF; buf[2] = (data >> 8) & 0xFF; buf[3] = data & 0xFF; and if you want this code to work on all systems (including wide-char ones), you need to make sure fwrite truncates too.

pwdisswordfish9 4y ago

Where is the ddevault bit?

jzm2k 4y ago
Probably this one: https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html