Date: Mon, 31 May 1999 09:23:01 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Dlanor Blytkerchan cc: djgpp AT delorie DOT com Subject: Re: -fpack-struct In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 30 May 1999, Dlanor Blytkerchan wrote: > >Dlanor Blytkerchan wrote: > >> My problem is this: the gcc info file says: "the offsets of the structure > >> members won't agree with system libraries". This is what worries me: what > >> does this mean and how likely is it that this will cause problems? > > Eli Zaretskii wrote: > >You could try the FAQ first. I think this issue is well explained in > >section 22.10 there. > > Naturally I checked the FAQ first, which didn't help me much, as it > recommends using an alternative sequence of members or the > __attribute__((packed)) thingy, which amounts to the same thing as using > the -fpack-struct compiler option. Either you have an old version of the FAQ, or perhaps you didn't quite understand what the FAQ explains. Let me try again. You asked (see above) whether using -fpack-struct could get you in trouble with system libraries. Here's a direct quote from section 22.10: If you use this switch, be sure that source files which you compile with it don't use *any* of the structures defined by library functions, or you will get some members garbled (because the library functions weren't compiled with that switch). I think this answers your question nicely. If not, please explain what is missing from this answer. > As using the __attribute__((packed)) > thingy amounts to the same thing as using the -fpack-struct compiler > option, that does not take away my reservations for using this. No, using __attribute__((packed)) is NOT the same thing as -fpack-struct, because the former only affects those structures whose definitions use __attribute__((packed)), whereas -fpack-struct affects *all* the structures in the module. Again, a quote from 22.10 explains this: Beginning with version 2.7.0, GCC has a command-line option `-fpack-struct' which causes GCC to pack all members of all structs together without any holes, just as if you used `__attribute__((packed))' on every struct declaration in the source file you compile with that switch. Therefore, __attribute__((packed)) does NOT have the potential problems with structures declared in system header files like -fpack-struct does, because I presume that you won't put any __attribute__((packed)) in the system headers. > Added to that, C++ will not allow this syntax, which does not cause > problems yet, but probably will in the future. Section 22.10 also tells you how to write code that will work with C++: However, note that the latter will only work when you compile it as a C source; C++ doesn't allow such syntax, and you will have to fall back to declaring each struct member with the packed attribute. It doesn't say you can't use it with C++, it simply says that, to be C++-safe, your code has to add __attribute__((packed)) to every struct member, not to the struct itself. Then it will work in C and C++ alike.