The Only Natural Alignment Is Byte Alignment

Posted May 16, 2012 10:03 UTC (Wed) by ldo (guest, #40946)
Parent article: Fixing the unfixable autofs ABI

This is why alignment on greater than one-byte boundaries should never be included in any interchange format or protocol, because invariably the architectural considerations that make them look like a good idea at one end in one situation will end up looking stupid at the other end or in another situation. And because it’s an interchange format, you cannot just simply change it without breaking compatibility.

Alignment only makes sense for internal program in-memory structures, which can be changed with a simple recompile and restart. Interchange formats should always be defined with no alignment padding. End of story.

The Only Natural Alignment Is Byte Alignment

Posted May 16, 2012 10:33 UTC (Wed) by amonnet (guest, #54852) [Link] (2 responses)

Look's like many protocol (think IPv4, etc) have been carefully crafted to provide natural alignment bigger than a byte. No padding but a nice choice of field size and position.
Anyway, it's not as if 16, 32, 64, .. are just some random numbers.

The Only Natural Alignment Is Byte Alignment

Posted May 16, 2012 10:50 UTC (Wed) by amonnet (guest, #54852) [Link]

To make things clear, alignment paddings in protocol are called private/unused/future fields.

The Only Natural Alignment Is Byte Alignment

Posted May 16, 2012 12:15 UTC (Wed) by paulj (subscriber, #341) [Link]

Sure, but all the fields' positions are still explicitly specified independently of any alignment concerns. I.e. the fields may have been constructed with regard for alignment, however the protocol doesn't depend on any alignment concerns.