Question

I previously posted a question here about aligned access during pointer casting. As a summary, it’s better not to use unaligned access to be fully portable because some architecture may throw an exception, or the performance may get quite slower compared to aligned access.

However, there are cases that I want to use one-byte alignment, e.g., during transferring network data, I don’t want adding extra padding inside structure. So usually what’s done here is:

#pragma pack (push, 1)
struct tTelegram
{
   u8 cmd;
   u8 index;
   u16 addr1_16;
   u16 addr2_16;
   u8  length_low;
   u8 data[1];
};
#pragma pack (pop)

Then you might already know my question: If I enforce one-byte alignment on my struct, does that mean it cannot be fully portable, because struct members are not aligned? What if I want both no padding and portability?

Answer 1

Firstly, misaligned memory accesses refers to single pieces of data that span multiple words in memory. For example: on a 32-bit system a 32-bit int at address 0, 4, 8 etc is aligned, but at 1, 2, 3, 5, 6, 7, 9 etc. would be misaligned.

Secondly, misaligned data doesn’t “throw an exception” in the C++ sense, but may raise an interrupt/trap/exception at the CPU level – e.g. SIGBUS on UNIX, where you’d generally set a signal handler to react to this, but if you need to parse misaligned data in a portable way you wouldn’t do so by catching signals – you’d manually code the steps to pack and unpack data spanning word boundaries.

In your tTelegram struct, the data is not “misaligned”, but the process of bit shifting and masking the data as it’s packed/unpacked from a register is still likely slower – requiring more machine code instructions – than using data that occupies an independent word.

Regarding portability – all non-toy compilers will have an option to pack in the way you’ve described, but the exact pragma will vary, the layout of bytes in multi-byte values may still be big-endian or little-endian (or something plain weird), and while some CPUs allow some misaligned data access (e.g. x86) others don’t (e.g. Ultrasparc).