why do structs have different sizes across machines?

[Jim Balter]

In article <77336 at bu.edu.bu.edu> jdubb at bucsf.bu.edu (jay dubb) writes:
>  struct tt
>    {
>      enum {P, PP} a;
>      char b[30];
>      int c;
>    };

>1) why exactly are the sizes different?

The size of the struct is the padded size; i.e., the size it will take
up as one element of an array.  A struct is always aligned on the boundary
of its most aligned member.  With a compiler that pads ints on multiples of
4, this struct will be aligned on a multiple of 4, and thus will have a size
that's a multiple of 4.  With a compiler that aligns ints on multiples of 2,
the struct will have size 4+30+4.  Also, int c will be aligned on a boundary
of 2 in one compiler (i.e., no padding) and a boundary of 4 in another
(i.e., 2 bytes of padding).  And, a compiler is allowed to allocate only
one byte for that enum, leading to yet other possible sizes (34, 36) for the
struct.  And if you have a 16-bit machine, the int would only be two bytes.

>2) what reprecussions does this have on sending the structures across
>   sockets between machines which pack them differently and trying to
>   interpret the fields on each end?

Er, don't do it.

>3) and most importantly, how can I avoid this problem? are there some
>   rules (for example, I know that all structures have to be a
>   multiple of 4 bytes large, and I know about compensating for byte
>   order differences, etc.) to be followed in making up structures
>   that will ensure that they are the same on any machine?

Transmit numeric values as a sequence of bytes, low-order byte first,
and turn them back into numeric values on the receiving end.  Do this
with right shifts and ANDs in the sender and left shifts and ORs in the
receiver, not unions or casts, so that the code is machine-independent.