-=> Quoting Paul Edwards to andrew clarke <=-

 > /* When compiled with Pacific C, this program prints:
 >    size is 4
 >    Yuck! */
 
 ac> It also prints 'size is 4' with Borland C++ for DOS 3.1 when compiled with 
 ac> the -a switch.

 PE> Crikey!  I've never seen that before.  Padding at the end of a
 PE> structure that contains only character variables!  Anyway, I looked up
 PE> the standard, and an implementation is allowed to pad between any
 PE> structure members, plus at the end, and there is no exception for

"The sizeof operator

When applied to an operand that has structure or union type, the result
is the total number of bytes in such an object, including internal and
trailing padding.   

The value of the result is implementation-defined"

Most 80x86 compilers align structures on 2 byte boundaries and some on 4
byte boundaries which is more efficient for 32 bit processors. 

In addition 80x86 processors cannot fetch data which crosses segment
boundaries (this is a real pain in 24 bit video requiring the programmer
to use inefficient code or include special case code for boundaries).

Large structures which cross segment boundaries should be on 16 byte
boundaries. I think that you will find that memory returned by memory
allocation functions is always on a 16 byte boundary.

 PE> char-only variables.  You know what that means, don't you?  You have
 PE> to read data from a file as a pure character buffer, you can't put it
 PE> into structures.

This has always been the case with C (COBOL is the only language which
allows the programmer total control over record I/O)

Most compilers allow a #pragma pack(1) or similar directive to force
structure packing. This allows implementation independent structure I/O.

You should NEVER output structures to files without packing (except for
temporary files).

Some programmers include explicit packing in structures to give
(processing) efficiency while retaining portability.


--- Blue Wave/386 v2.30