Curtis L. Olson wrote:
> Hmmm, I see write away that even if I use int8_t or int16_t, they still
> get padded out to 4 bytes in the structure that is sent across the net
> (on 32bit Linux.) Does that mean we always want to use int32_t to avoid
> potential confusion, or is this situation ok?
Most compilers have a set of switches you can use to control structure
padding and alignment. But indeed, there's nothing in the spec that
says what the proper alignment should be.
FWIW, every compiler I know stores each element in order, and pads it
up to its "natural" alignment. So this struct takes 8 bytes in memory
on all platforms I know:
struct { int8_t a; int8_t b; int32_t c; }
But this one takes at least 12 (word-size padding is added at the end
on most or all compiler):
struct { int8_t a; int32_t b; int8_t c; }
So long as the structure honors those rules, you should be more or
less portable. Other options are, obviously, to store everything as a
int32_t and do the bit packing yourself. You'll need to do this in
any case if you want endian compatibility. This is one of the many
reasons that dumping structures from memory to I/O is considered
problematic. :)
Andy
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
