In the two macros, the only alignment that matters is the alignment of addr
. As written in the question, they are equivalent if addr
is 32-bit aligned (meaning its low two bits are zero), but only if the target architecture is also little-endian.
On a big-endian machine, the upper 16 bits of pixels
must be written to (INT16*)(addr))[0]
and the lower 16 bits to (INT16*)(addr))[1]
for them to be equivalent.
Without checking my copy of the libjpeg source code, I'd guess that these definitions are either expected to be modified as part of porting the library, or they are already guarded by a declaration of endianness.
If addr
is not 32-bit aligned, then the WRITE_TWO_ALIGNED_PIXELS
macro might cause an exception to be thrown on architectures where unaligned access is not permitted. Of course in some cases, unaligned access is permitted, but is much more expensive than two smaller aligned accesses, and on some other architectures, unaligned access is difficult to distinguish from aligned access.
The two macros exist as a reminder to the author of the library to think about alignment, and to standardize the approach to handling misaligned access so that it can be optimized out when building for platforms where it doesn't matter.