Around 23 o'clock on Jan 11, Thiemo Seufer wrote: > Exactly. xlib seems to use the sum of the size of the primitives in an > element instead of the size of the first element. No, Xlib assumes that the alignment of the struct or union is the alignment of the most restrictive element in that struct or union. Before ANSI C (note, not C99, but the original ANSI C which postdates Xlib), this was the way C worked. That ANSI C permits more 'flexible' layout is an ABI incompatible change between K&R and ANSI C. We're talking here about a struct containing two chars. On almost every machine we've seen, save the ARM, this is two bytes. Would a structure containing an array of two bytes also be padded to four bytes on this architecture? However, instead of bashing this lunacy in the ARM ABI further, we should accept that it cannot be changed without breaking tons of existing code. I suggest that we just stick an appropriate #ifdef in the Xlib header to 'pack' this structure on the ARM platform. With autotools, we will even detect this strange situation automatically. Is there some temporary kludge we can apply to get the imake Xlib header file working? -keith
Attachment:
pgpNLmUx0Dcp0.pgp
Description: PGP signature