[lug] More packing troubles...

Tom Tromey tromey at redhat.com
Mon Jun 11 20:33:36 MDT 2001


>>>>> "David" == David Trowbridge <jupiter at flatirons.org> writes:

David> I just now ran into the same problem with porting a network app and
David> #pragma pack. My problem is this: in the app, before a network command
David> structure, there are these two lines:
David> #pragma pack (push, pre_spi)
David> #pragma pack (2)
David> and ending with this after the struct:
David> #pragma pack (pop, pre_spi)

David> I've defined HAVE_PRAGMA_PACK_PUSH_POP to 1, but I get the
David> following error

HAVE_PRAGMA_PACK_PUSH_POP is a gcc back-end macro.  It is only used when 
building gcc itself.  There's no point in defining it in your code.

HAVE_PRAGMA_PACK_PUSH_POP is defined for all Linux targets.  So this
feature should be available in your Linux gcc.  You could try
compiling with `-Wunknown-pragmas' to verify this.

David> and can't find any docs on the exact format gcc wants:
David> spi.h:35: warning: malformed '#pragma pack(push[,id],<n>)'
David> spi.h:35: warning: ignoring pragma:

I looked at the manual and I also didn't see anything.  Well, there's
some stuff in tm.texi, that's lame since that document is describing
the back end and not what users ought to do.  Could you submit a gcc
bug report for this?  It is very easy to do:

    http://gcc.gnu.org/bugs.html


The text in tm.texi, which is part of gcc 3.0, says (I just extract
the Texinfo):

    The pack(push,<n>) pragma specifies the maximum alignment
    (in bytes) of fields within a structure, in much the same way as the
    @samp{__aligned__} and @samp{__packed__} @code{__attribute__}s do.  A
    pack value of zero resets the behaviour to the default.  Successive
    invocations of this pragma cause the previous values to be stacked, so
    that invocations of @samp{#pragma pack(pop)} will return to the previous
    value.


I'd advise not using these pragmas if you possibly can avoid it.  I
imagine (though I'm not positive -- the back end isn't really my area)
that the resulting code it will be slow.

Tom



More information about the LUG mailing list