[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Struct packing/alignment problems
From: |
Timmy Brolin |
Subject: |
Re: [lwip-users] Struct packing/alignment problems |
Date: |
Wed, 05 May 2004 17:59:25 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
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
- Re: [lwip-users] Struct packing/alignment problems, (continued)
- Re: [lwip-users] Struct packing/alignment problems, Leon Woestenberg, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, K.J. Mansley, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Jani Monoses, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Leon Woestenberg, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Jani Monoses, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Timmy Brolin, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Leon Woestenberg, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Timmy Brolin, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, K.J. Mansley, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, Leon Woestenberg, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems,
Timmy Brolin <=
- Re: [lwip-users] Struct packing/alignment problems, Leon Woestenberg, 2004/05/05
- Re: [lwip-users] Struct packing/alignment problems, K.J. Mansley, 2004/05/04
- Re: [lwip-users] Struct packing/alignment problems, Timmy Brolin, 2004/05/04
RE: [lwip-users] Struct packing/alignment problems, Mountifield, Tony, 2004/05/04
RE: [lwip-users] Struct packing/alignment problems, Mountifield, Tony, 2004/05/05