[EMAIL PROTECTED] wrote:
Then shouldn't changing the order of the members fix that
typedef struct tagKeyBlock
{
unsigned long nHash_:32 ;
unsigned int nSerialNumber_:16 ;
unsigned int nVersion_:8 ;
} KeyBlock;
nHash is of course OK
nSerial is at a 2 byte boundry
nVersion is at a 1 byte boundry
This was taken from a gcc project which builds fine and the sizeof is 7 on GCC.
On CW it's still getting padded to 8 no matter what pragma options I provide.
What happens if you do this?
KeyBlock kbs[5];
kbs[1].nHash_ = 42;
If sizeof(KeyBlock) is 7, then either arrays get extra padding or
accessing odd elements of the array causes odd-address problems.
And if arrays get extra padding, then ((char *) kbs) + sizeof(KeyBlock)
would no longer equal (char *) (kbs + 1), since kbs[1] is equivalent
to *(kbs + 1). And that would be just weird, and I think not legal
for C either.
Naturally, the compiler could just generate code to access the elements
one byte at a time and avoid the word alignment issue, but the speed
penalty would be big.
- Logan
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
