3 ms·

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 embe

by 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.

by pdw 4y ago

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.