Re: alignment

[Guy Harris <guy () netapp com>]

On Sat, Nov 09, 2002 at 11:50:17AM +0900, Jun-ichiro itojun Hagino wrote:
> > >    if not, is it acceptable if we test the feature in
> > >    configure.in and use it if available?
> > I'd say so (as long as this doesn't involve peppering the code with
> > #ifdefs - if the feature *isn't* available, you still have to use the
> > EXTRACT macros),
>
>       i was thinking about something like this:
>
> #if GCC
> #define __ATTRIBUTE_PACKED__  __attribute__((packed))
> #else
> #define __ATTRIBUTE_PACKED__
> #endif
>
> struct foo {
>       u_int32_t bar;
>       u_int32_t baz;
> } __ATTRIBUTE_PACKED__;

Or just use "__attribute((packed))", as "interface.h" does

        #ifndef HAVE___ATTRIBUTE__
        #define __attribute__(x)
        #endif

so that __attribute__ is no-oped out if the compiler doesn't support it.

(Yes, this breaks if there's a compiler that supports it in a
non-GCC-compatible fashion, but there's already stuff in tcpdump that
depends on __attribute__ either not existing or working as it does in
GCC.)

Presumably then you'd do

        #if defined(LBL_ALIGN) && !defined(HAVE___ATTRIBUTE__)

or something such as that in "extract.h", so that raw "ntohs()" and
"ntohl()" will be used if either

        1) the platform supports efficient unaligned memory accesses
           (LBL_ALIGN isn't defined)

or

        2) the platform supports __attribute__((packed)) so that the
           compiler will generate reasonably efficient code to fetch
           unaligned stuff

and then convert references to use the EXTRACT_ macros.

> > although note that "__attribute((packed))", at least
> > according to the GCC 3.2 manual:
> >
> >     http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Variable-Attributes.html#Variable%20Attributes
> >
> > changes the layout of the structure, so you'd have to add padding to
> > structures that lack it.
>
>       if they don't have padding, they do not work right even now.

I.e., a structure

        struct foo {
                u_int32_t       a;
                u_int8_t        b;
                u_int32_t       c;
        };

won't work as a packet format description - you have to use

        struct foo {
                u_int32_t       a;
                u_int8_t        b;
                u_int8_t        pad[3];
                u_int32_t       c;
        };

?  If so, are there any structures of the sort that won't work?
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe