[Xcb] [PATCH] Force XCB event structures with 64-bit extended fields to be packed.

[Kenneth Graunke]

On 12/31/2013 12:06 AM, Mark Kettenis wrote:
>>  With the advent of the Present extension, some events (such as
>>  PresentCompleteNotify) now use native 64-bit types on the wire.
>>
>>  For XGE events, we insert an extra "uint32_t full_sequence" field
>>  immediately after the first 32 bytes of data.  Normally, this causes
>>  the subsequent fields to be shifted over by 4 bytes, and the structure
>>  to grow in size by 4 bytes.  Everything works fine.
>>
>>  However, if event contains 64-bit extended fields, this may result in
>>  the compiler adding an extra 4 bytes of padding so that those fields
>>  remain aligned on 64-bit boundaries.  This causes the structure to grow
>>  by 8 bytes, not 4.  Unfortunately, XCB doesn't realize this, and
>>  always believes that the length only increased by 4.  read_packet()
>>  then fails to malloc enough memory to hold the event, and the event
>>  processing code uses the wrong offsets.
>>
>>  To fix this, mark any event structures containing 64-bit extended
>>  fields with __attribute__((__packed__)).
> 
> The problem with that approach is that this is a GCC-ism that isn't
> portable.  I believe the sun studio compiler supports something similar. 
> But other compilers might not.

Yes, it's unfortunate to have to resort to this.  That said, GCC, Clang,
and Sun Studio 12 Update 1 support __attribute__((__packed__)).  So it's
pretty widely accepted.  Not sure about older Sun Studio.

MSVC doesn't support this attribute, but does allow you to force packing
via #pragma pack.  I believe that may also work in GCC, Clang, Sun
Studio, but I haven't tried it personally...

> C11 has _Alignas(), but it is a tad bit early to start relying on this.
> 
> I also don't quite trust the compiler to get to emit the right
> instructions for unaligned access on all platforms.

I would be really surprised if it didn't.  If a compiler can't generate
code to read a field of a packed structure in 2013 (even
inefficiently)...wow, that's a bad compiler.