Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!rice!eunomia.rice.edu!bro
From: bro@eunomia.rice.edu (Douglas Monk)
Newsgroups: comp.sys.atari.st
Subject: Re: cross-compiling
Message-ID: <1990Nov1.012001.25362@rice.edu>
Date: 1 Nov 90 01:20:01 GMT
References: <1990Oct29.235921.23294@math.lsa.umich.edu>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 33


In article <1990Oct29.235921.23294@math.lsa.umich.edu> hyc@math.lsa.umich.edu
 (Howard Chu) writes:
[re: byte padding on Sparcstations]
>[...] always tries to align structure elements on longword
>boundaries.
>[...] The structure, as defined,
>is 28 bytes on an ST, and 32 bytes on a Sparc. Bleah.)

I ran into the same problem years ago between Suns (1s) and Vaxen. (Plural of
Vax :-) Since we weren't sure at the time what else might be called for in 
the future, we started reading and writing structures as the component 
independent low level objects (shorts, longs, and bytes), and since we also 
wanted to be prepared for *byte-order* variations, we used the byteorder 
macros used for networking portability (htonl, htons, ntohl, ntohs) so it 
could run on *anything*. On a Sun 2/3/4 these are null macros, since the size
and byteorder of shorts and longs are the network standard. Other machine 
architectures (like Vaxes, '386s, etc.) provide macros to convert to and from
network standard sizes and orderings. You still have to fool about a bit with
ints: I always casted them to longs to be safe before converting :-).

Haven't had a bit of trouble since.

Moral: a little extra effort, even when it is *really* a no-op *now* may
save a *ton* of trouble later.

Oh, yeah, and *never* trust compilers to construct structures in any *sane*
way: if byte padding can take place, is there any reason for a compiler even 
to maintain the same order for components as declared within a structure?

Doug Monk (bro@rice.edu)

Disclaimer: These views are mine, not necessarily my organization's.