Re: [lwip-users] Struct packing/alignment problems

[Timmy Brolin]

K.J. Mansley wrote:

> On Wed, 2004-05-05 at 14:27, Timmy Brolin wrote:
>  
>
> > To put and end to the gcc+arm debate, I fired up my gcc arm compiler and 
> > ran the example below on my gameboy advance :-)
> > The offsets are as expected: 0, 1, 2.
> >
> > I also ran the example in Microsoft Visual Studio 6.0
> > Same result.
> >
> > So now it is verified to work with at least three compilers.
> >    
> Ok, carry on and let us know when you've done them all :)
Will do. I'll post the results tomorrow ;-)

>  Be very wary
> of extending "it works on some systems" to "it works on all systems" and
> also "this simple test works" to "all code that does something like the
> simple test will work".
I did not say that.

> As far as I can see the pros and cons for removing the packed directives
> are:
>
> Pro:
> - makes slightly cleaner code
>
> Con:
> - may not work on all compilers and platforms
>
> No one has yet proved or disproved this con, but the possibility of it,
> in my opinion, outweighs the minor issue of cleaner code.  The C
> standard does not seem to provide a solid assertion that we can rely on.
> (No one has been able to find that assertion anyway).  If I'm honest,
> you're probably right that removing it won't cause problems, but why
> change it if it isn't broken?
Or the other way around: Don't fix something that aint broken. (The pack 
directives are a fix for a problem that does not exist anymore)
Don't underestimate the importance of clean code.
If the structs are fine without the pack directives, then there should 
be no pack directives in the code.
Note that not all compilers support pack directives, and pack directives 
are not in the C standard at all.

I have been searching comp.std.c and found several relevant quotes from 
the C standard:
3.5.2.1
#  Within a structure object, the non-bit-field members and the units
#  in which bit-fields reside have addresses that increase in the order
#  in which they are declared.  A pointer to a structure object, suitably
#  converted, points to its initial member (or if that member is a bit-
#  field, then to the object in which it resides), and vice versa.
#  There may therefore be unnamed holes within a structure object,
#  but not at its beginning, AS NECESSARY TO ACHIEVE THE APPROPRIATE
#  ALIGNMENT.
#
#  ... There may also be unnamed padding at the end of a structure,
#  AS NECESSARY TO ACHIEVE THE APPROPRIATE ALIGNMENT were the structure
#  or union to be an element of an array.
(emphasis added)

"alignment" is defined in 1.6 as
#  a requirement that objects of a particular type be located on storage
#  boundaries with addresses that are particular multiples of a byte 
address.

The text is pretty clear on the fact that holes in structs are allowed 
only if necessary to archive alignment. And we have already established 
that the alignment requirements of a type may not be larger than it's size.
I think that while it may not be expressively stated in the C standard, 
it is definitely implied when you put the two quotes above together (and 
the fact that alignment requirements must be equal or smaller than the 
size of a type).

> Quite frankly though, we have much more important things to worry about,
> and this is starting to cloud other issues.  There doesn't seem to be a
> consensus one way or the other, so I'm not sure of the best way to
> resolve it. The macros will have to remain in the code for the Ethernet
> ARP header, if I understand that correctly, so it really isn't worth
> worrying about.  Leon: you seem to have been following this without
> getting too involved, perhaps you could make a decision on this so we
> can forget about it for the time being?
No, the alignment fix posted a couple of days ago solves the etharp 
header problem. There is no need for pack directives in any struct after 
the alignment patch is applied.

Timmy

> Thanks,
>
> Kieran