On Sat, Jan 24, 2015 at 3:03 PM, Nevin Liber
On 24 January 2015 at 12:00, Beman Dawes
wrote: In practice, the enhanced efficiency of aligned types is usually more important than worry about someday encountering an odd-ball architecture or use in an unaligned location.
I disagree with that for endian. Most of those uses are in wire and file protocols, and they are either densely packed or based on the alignment of the original architecture that the protocol was developed on.
I agree with you that a lot of uses are for legacy formats, but my experience has been that most of those observe 16 and 32-bit alignment rules that are the same as we need today. 64-bit values may be a different story - I have virtually no experience with legacy formats that use 64-bit data. But regardless, the endian library must support both aligned and unaligned. I'm warming to Jeremy Maitin-Shepard's suggestion in a later post that we use explicit names for both aligned and unaligned types.
Unless one is transferring data between machines with different architectures, why would one use endian at all?
Most of us write programs for little-endian architectures that deal with big endian wire and file formats. Thanks, --Beman