Date:	Tue, 31 Oct 1995 09:20:43 -0500
From:	kagel AT quasar DOT bloomberg DOT com
To:	eliz AT is DOT elta DOT co DOT il
Cc:	gt7010a AT prism DOT gatech DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: Determining proper sizeof a struct
Reply-To:	kagel AT ts1 DOT bloomberg DOT com

   On Mon, 30 Oct 1995, Ojas Parekh wrote:

   > This program prints a value of 148 for sizeof(ulfrec) under both
   > DJGPPV2 and DJGPP 1.12m4, but the value should be 146.
   > Compiled under BC 3.1, this same program reports 146 for
   > sizeof(ulfrec) as it should.  Is there something about gcc/DJGPP
   > data types that I am not aware of?  Thanks.

On Tue, Oct 31, 1995 Eli Zaretskii replied:

   Gcc (and other 32-bit compilers) pad structures so that they could be 
   accessed faster by 32-bit processors (there is a penalty of accessing 
   unaligned addresses).  It is usually wrong to assume that sizeof of a 
   struct is the sum of the sizes of its fields; 16-bit DOS-based compilers 
   just proliferate this bad habit by not padding structures, because it's 
   much less important in 16-bit code.

   If you need to make the structure packed (i.e. without padding holes), 
   you should use the Gcc ``__attribute__ ((packed))'' extension (described 
   in Gcc Info manual), but this should only be used when the structure must 
   fit some external specification, like a specific data layout of a device 
   driver or a hardware peripheral.

Also note that besides the obvious one byte pad after the field 'sizemod' to
align the next field (blocks) on an even address, there is a one byte pad at
the end of the structure, after the field 'res', to maintain alignment of the
next element of any array of 'struct ulfrec' on a 4byte address (so that the
contained long field 'vpointer' is aligned in subsequent elements).  This
brings the total size up to 148 bytes.

-- 
Art S. Kagel, kagel AT ts1 DOT bloomberg DOT com

Variety is the soul of pleasure.  --  Aphra Behn

- Raw text -