Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!bu.edu!encore!boykin@encore.com
From: boykin@encore.com (Joseph Boykin)
Newsgroups: comp.unix.programmer
Subject: Re: why do structs have different sizes across machines?
Message-ID: <14365@encore.Encore.COM>
Date: 20 Mar 91 16:39:46 GMT
References: <77336@bu.edu.bu.edu>
Sender: news@Encore.COM
Reply-To: boykin@encore.com
Distribution: usa
Organization: Encore Computer Corp.
Lines: 64
Nntp-Posting-Host: encore.encore.com

In article <77336@bu.edu.bu.edu>, jdubb@bucsf.bu.edu (jay dubb) writes:
|> 
|>    I am posting this for a friend of mine who doesn't have access
|> to USENET, so please respond directly to mlevin@jade.tufts.edu.
|> 
|>    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:

The reason is that sizeof(structure) is not the same in different
machine architecutres.  If you had a 64-bit int on one machine
and 16 bits on another, it would seem obvious that sizeof(struct)
would return different values.  Another reason is that sizeof()
is supposed to return the amount of space used, *plus* whatever
is necessary for alignment to a machine boundary.  So swapping
the 'b' and 'c' members of your structure on the Multimax would
still yield the same results.  Last, word alignment within the
structure may be different for different machines.  Alot of CISC
architectures can access 32-bit values which are only aligned on a
16-bit boundary, but at a performance penalty.

|>   struct tt
|>     {
|>       enum {P, PP} a;
|>       char b[30];
|>       int c;
|>     };

In your particular case, the enum and int are (coincidentally) the same
on both machines.  On the multimax, int's are aligned on 32-bit boundaries
hence the character array gets padded.  On the SUN 3 (68K) you don't
have to align on 32-bit boundaries (although memory access is faster if
you do), and apparently the SUN compiler isn't doing the alignment.

Hence the problem of transferring structures across machine boundaries.
It's reasons like this why Mach IPC (and other systems) types the data
on transfer.

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

Since sockets are a simple byte stream, there isn't a way of
sending structures between two unknown system architectures and
assuring that you will see the same thing on both ends.

The simpler case of sending between two known machines can be dealt
with by making sure that all structures and structure members are
aligned on 32-bit boundaries.  Often, there is a compiler switch to do
this.  Of course, this won't help if you're dealing with a 64-bit
machine, but that's probably not a major concern right now!

You'll also need to consider byte ordering.

----

Joseph Boykin
Manager, Mach OS Development
Encore Computer Corp
Treasurer, IEEE Computer Society

Internet: boykin@encore.com
Phone: 508-460-0500 x2720