Date:	Tue, 24 Sep 1996 13:35:36 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Ryzhenkov Ilya <ilya AT spy DOT isp DOT nsc DOT ru>
Cc:	DJGPP Mailing List <djgpp AT delorie DOT com>
Subject:	Re: Structure package problems
In-Reply-To:	<32475B30.5E66@spy.isp.nsc.ru>
Message-Id:	<Pine.SUN.3.91.960924132416.11664E-100000@is>
Mime-Version:	1.0

On Mon, 23 Sep 1996, Ryzhenkov Ilya wrote:

> I was creating an application to dump object (.o) file structure
>  (similar to objdump) mainly to understand coff format. I've included
>  coff.h and just used open,read,lseek in binary mode to read data in the
>  structures of coff.h types (SYMENT,FILHDR etc). Things was completely
>  messed up! (It was mainly in SYMENT struct)
>  Yes, I've read the FAQ and added the following lines :
> 
> #pragma pack(1)
> #include <coff.h>
> #pragma pack()
> 
>  All becomes fine. No bugs, no data messing. But ....
> 
>  Is it so necessary to force user to overcome that very things ? Can
>  #pragma statements can be placed in the coff.h (and similar files) ?
>  How BFD was compiled ? Was -fpack-struct was used or it was smth other ?

You only need this pragma if you are compiling a C++ program.  Only the 
C++ compiler has this bug.  Is there any reason why you should use a C++ 
compiler with that header?

>  (FAQ says that compiler incorrectly process tails of structs
>  even if __attribute__((packed)) is used, but in <coff.h> for example that
>  attribute was used for a few fields).

The FAQ doesn't say this is an incorrect behavior.  The FAQ say that even
if you instruct the compiler to pack the struct fields, it still can pad
the struct at the end.  That is because if you declare an array of such 
structs, the next element of the array does not have to follow 
immediately after the previous one.  This is (IMHO) correct behavior, but 
whoever messes with packed structs should be aware of it.

- Raw text -