What I found out is that default for the 64 bit gcc compiler is to enable padding to maintain dword memory alignment in structures. This is what is causing the seemingly weird results with your sizeof() test code. sizeof() can return more than the obvious number of bytes due to padding. See Data Alignment in Structs for some more info. There is a way in gcc to override this behavior if perhaps you need to match some weird binary structure exactly verbatim. Just like malloc(), struct address assignment "likes" dword (64 bit alignment).
Evidently, even putting something in the struct that has no storage, like char* pointer[], forces alignment bytes to be added. The mysterious extra 4 bytes aren't anything, they are just junk padding bytes. The pointer(s) when added will be 8 bytes and it is highly desirable for these to be fully contained on a single memory row. If they are on 32 bit boundaries, the hardware can still read them, but at a performance penalty.typedef struct _foo { int count; //with just int, sizeof() is 4 bytes char anything; //forces sizeof() increase from 4 to 8 bytes! } foo;
So my code as written performs correctly, however the explanation of why the struct is 8 bytes is not correct. 4 bytes are for the integer (not 8 as I wrongly assumed) but then an additional 4 bytes are added as padding. 4+4=8. So the entire array of pointer is 64 bit aligned (8 byte boundary).
In reply to Re^9: Perl XS binding to a struct with an array of chars*
by Marshall
in thread Perl XS binding to a struct with an array of chars*
by MaxPerl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |