Previous "discussion": https://news.ycombinator.com/item?id=31077574 https://news.ycombinator.com/item?id=31077574 As it has only one comment, let me copy-past

Previous "discussion": https://news.ycombinator.com/item?id=31077574 https://news.ycombinator.com/item?id=31077574 As it has only one comment, let me copy-paste it in full, below. --- I have read the article, and my first reaction is to disagree with the conclusions. The whole problem stems from the fact that the units in which the data is accessed by the ("strange") CPU and by the external storage can be different. Let's suppose that the CPU-character is 16-bit wide (i.e. that the CPU can't address or process 8-bit data units individually), while the storage-character is 8-bit wide. In that case, both the behavior of writing each CPU-character as two storage-characters, _and_ the behavior of writing only the 8 bits of each CPU-character to storage, might make sense, for different applications. This is not really about truncation, this is about choosing an interleaved or non-interleaved representation of the storage content in memory as the source layout. And yes, for the representation where each storage-character is represented by one CPU-character, it is logical that the higher 8 bits can't matter, must be ignored, and so the program can return 2 in this case. The real bug here is the attempt to stipulate one and the same storage representation for all applications. This should ideally be a flag to fopen(), just like we have a "b" flag to denote binary streams on some systems. I think it is too late to rule on the default, though.