Re: [PATCH] Do not warn about char __attribute__((packed))

[Nathan Sidwell <nathan at codesourcery dot com>]

Richard Guenther wrote:
> On Thu, 15 Dec 2005, Nathan Sidwell wrote:
>
>
> > Richard Guenther wrote:
> >
> > > Recently the following warning was introduced, which triggers in
> > > cases where it doesn't make any difference if its packed or not, like
> > >
> > > /usr/src/linux/include/asm/mpspec_def.h:
> > >   [...]
> > > 74 struct mpc_config_bus
> > > 75 {
> > > 76        unsigned char mpc_type;
> > > 77        unsigned char mpc_busid;
> > > 78         unsigned char mpc_bustype[6] __attribute((packed));
> > > 79 };
> > >
> > > The following patch changes the logic to only warn if we try to
> > > pack things that have type alignment smaller than BITS_PER_UNIT.
> >
> > Are there such types?  Are there systems where the alignment of array of Foo
> > is greater than plain Foo? (I.e. are there systems where the above attribute
> > does something?)
>
>
> I doubt it.  But 6.7.2.1/12 doesn't tell anything special about
> array members, so it might be aligned differently and still be
> standard conformant.

But 6.7.2.1/13 tells us that we have no guarantee that mpc_busid is packed 
closely to mpc_type.  6.2.5/20 first bullet tells us about array types, but 
doesn't tell us whether the aligment comes purely from the element type, or is a 
combination of element type and number of elements.  However, because an array 
of unspecified bounds is compatible with any array of a particular bound, one 
can deduce the number of elements cannot make a difference to the alignment 
requirements.

If we consider 6.7.2.1/13,  we could beleive it without considering context, and 
there can arbitrary padding anywhere except before the first field.  So we 
should pack the whole structure.  Alternatively we believe the above argument 
that both char fields and arrays of char are equally closely packed, and so have 
no need to pack mpc_bustype.

I've had a long conversation with Nick Maclaren concerning structs of the above 
form.  He is of the opinion that any ABI that added any padding would not be a C 
ABI in the real world.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk