why do structs have different sizes across machines?

[der Mouse]

In article <77336 at bu.edu.bu.edu>, jdubb at bucsf.bu.edu (jay dubb) writes:
> Can anyone explain to me why the following short program give the
> size of the structure as 38 on a Sun 3, and 40 on an Encore Multimax:

This is a C question, not a UNIX question.  I'm crossposting to
comp.lang.c and pointing followups there.

> main()
> {
>   struct tt
>     {
>       enum {P, PP} a;
>       char b[30];
>       int c;
>     };
>   printf("%d\n",sizeof(struct tt));
> }

> I notice that making the size of b[] 32, makes the structure be 40
> bytes large on both machines.  I imagine thiis is due to the way the
> machines align fields in structures.

Bingo.

> I am worried since I am trying to send structures across sockets
> between en encore and a sun machine.

You have only two choices.  One is to assume that the machines on the
ends of the connection are, say, a Sun-3 or an Encore, and carefully
write your code so it works in all those cases.  This is not a good
idea unless you absolutely must get all the speed possible out of it,
because the other alternative is much more portable and maintainable.

The other choice is to put the structure in some portable form for
transmission over the connection.  This could mean anything from
judicious use of ntohl() and related routines to converting everything
to text.  This slows you down, of course, but in the vast majority of
the cases the gain in portability and maintainability is worth it.

> So, can someone enlighten me about the following things:

> 1) why exactly are the sizes different?

In this case, because the Sun-3 is willing to align the int on a 16-bit
boundary while the Encore inserts two bytes of padding to move it to a
32-bit boundary.  (I feel sure this is true, though I have no access to
an Encore to check.  If I have it wrong and you *have* checked, feel
free to correct me.)

> 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?

It is only the tip of the iceberg.  Basically, you don't want to send
structures in raw binary unless you really really don't care about
portability (for example, the application should be one you're willing
to write in assembly for - as a rough rule of thumb).

> 3) and most importantly, how can I avoid this problem?

You can't, portably.  You have to convert to some sort of interchange
format.

>    are there some rules (for example, I know that all structures have
>    to be a multiple of 4 bytes large,

They don't really; a VAX would be perfectly happy with a 7-byte
structure.  (I don't recall offhand whether there exists a VAX C
compiler that doesn't pad structures.)  A Sun-3 is quite happy provided
only that everything is a multiple of 16 bits.

>    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?

No.  There are just too many weird machines out there.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu