libraw1394 struct layouts, i386 vs. x86_64

[Jerry Feldman]

On 01/07/2009 04:10 PM, Ben Scott wrote:
>   But copying C headers around like that is also a bad idea, for the
> very reason you're encountering: The C standard provides no guarantees
> about how struct's will be laid out in memory.  The compiler can do
> (and often does) whatever it want.  As we see here, compilers often
> align/pad struct's to optimize for the architecture they're targeting.
>
>   
Many times it is the calling standard that mandates alignment, not the 
compiler. The compiler is required to maintain the order of the elements 
in a struct. Calling standards usually require that a struct be aligned 
on the longest natural boundary (on a 64-bit system it would be 64-bit). 
Then elements themselves are aligned to their natural boundaries. In 
i386 you will find that ints are usually on 32-bit boundaries, but 
doubles are also on 32-bit boundaries eventhough doubles are 64-bits 
wide. Additionally, in some systems accessing an element (say 64-bit 
long) that is not properly aligned will cause an exception. Some systems 
will trap and perform a fixup resulting in poor performance, and others 
will cause the application to crash. In developing the assembler windows 
NT on the Alpha, the WNT object file format had to be packed.

Additionally, pragmas are not standard and are implementation defined. 
The behavior or #pragma pack on GCC/G++ may be much different than 
#pragma pack on Visual C++. Avoid pragmas if you can, otherwise wrap 
them in #ifdefs.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20090108/ae10fd35/attachment.bin