Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!hellgate.utah.edu!cc.utah.edu!inel.gov!gem-hy!cdm
From: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Newsgroups: comp.unix.internals
Subject: Re: Re:word alignment for structures in UNIX
Message-ID: <1990Sep26.211648.21594@inel.gov>
Date: 26 Sep 90 21:16:48 GMT
References: <5020@quiche.cs.mcgill.ca>
Sender: news@inel.gov
Reply-To: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Lines: 85

In article <5020@quiche.cs.mcgill.ca>, mikey@quiche.cs.mcgill.ca
(Michael GALLOP) writes:
|> Sorry, my rn is busted...I gotta do this by hand.
|> In article 20631 <4046@quiche.cs.mcgill.ca > (adr@quiche.cs.mcgill.ca)
|> (Alain Durand) writes:
|> >
|> >Hello,
|> >
|> >       I've troubles with word alignments on different unix machine:
|> >sizeof(struct foo) doesn't return the same thing on a sun3, sun386i
|> >and sparc. Is there an option to set at compilation time or somewere
|> >in the kernel to fix that?
|> >thanks for any answer, please reply by E-Mail at:
|> >
|> >adr@quiche.cs.mcgill.ca
|> 
|> 
|> 
|> 
|> 
|> Please note: The poster is only a grad student at Mcgill and does not
reflect 
|> the undergrad education :- ) 
|> 
|> 
|> Well Alain. There are several different factors. First off when
dealing with 
|> any two machines, your request will likely return different values. 
|> 
|> 
|> One of the reasons-perhaps the main one- is the different architectures in 
|> the CPUs of the machines. From what I remember 80X86 swaps the bytes around 
|> from the way the SPARC deals with them 
|> 
|> 
|> More importantly is the difference in word size. An 80386 is a 32 bit
machine 
|> -in some modes. In fact all of these are 32 bit machines. However the 
|> register addressing is different on each one. The Sparc uses circular 
|> addressing, whereas the i386 uses a form of virtual addressing. 
|> 
|> Further, an important factor is the overhead of your C compiler, your OS. 
|> These _MIGHT_ ( probably won't) affect the result returned.... 
|> This, coupled with the different ways that each OS allocates memory 
|> will result in your observations. 
|> 
|> 
|> Why, though are you asking ? You can't magic number a (Not can't-
shouldn't) 
|> malloc. So you should 
|> if ( ( malloc ( sizeof ( foo ) ) ==NULL ) 
|> or whatever is needed. 
|> 
|> As for patching it in the kernel, I couldn't possibly see why, or
how, you'd 
|> do that. By hard wiring a value like that in the kernel, you cause havoc in 
|> the rest of the OS. Especially in a 386. If you were to do that on a 386 in 
|> 386 protected mode, or, worse in virtual 8086 mode, the page frame would 
|> cause a memory fault- I should know, I spent many hours chasing my mistake 
|> on that one I tried to align with a magic number :- ( -and dump the
machine. 

I just finished working a file transfer project, and had to deal with 
exactly this issue.  Aside from obvious considerations of differring 
word sizes, I found the most important consideration to be the "padding"
each compiler adds to the end of the structure.  Some pad to floating
point word boundaries, some to character boundaries, others pad to the
end of the largest item allocated in the structure.  Typically, the
padding comes into play for structures containing character strings,
but short int is another to watch out for.

Neither the United States Government nor the Idaho National
Engineering Laboratory nor any of their employees, makes any warranty,
expressed or implied, or assumes any legal liability or responsibility
for the accuracy, completeness, or usefulness of any information,
product, or process disclosed, or represents that its use would not
infringe privately owned rights.  Reference herein to any specific
commercial products, process, or service by trade name, trademark
manufacturer, or otherwise, does not necessarily constitute or imply
its endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions of authors expressed herein do not necessarily state or reflect
those of the United States Government nor the Idaho National Engineering
Laboratory, and shall not be used for advertising or product endorsement
purposes.