Mail Archives: djgpp/1999/05/31/02:25:19
On Sun, 30 May 1999, Dlanor Blytkerchan wrote:
> >Dlanor Blytkerchan <dlanor AT dds DOT nl> 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 <eliz AT is DOT elta DOT co DOT il> 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.
- Raw text -