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

[Kieran Mansley]

On Tue, 4 May 2004, Timmy Brolin wrote:
> The reason the compiler inserted padding in the example on
> linuxdevices.com is because the struct fields were unaligned!
> Assuming char is 8bit, short is 16 and int is 32, field b is unaligned.
>
> The complier inserts one byte padding between field a and b to remedy
> this. And there is no performance difference in accessing a 16bit
> variable from a 2byte boundary or a 4byte boundary. Obviously you have
> not programmed much assembly :)

Smiley noted.

"The ARM Linux compilers round the size of structures to a multiple of 4
bytes and always align structures to a multiple of 4 bytes so that the
load and store multiple word instructions (ldm and stm) can be used"

(Taken from
http://www.handhelds.org/z/wiki/Porting%20Software%20to%20ARM%20Linux
as part of a very brief discussion about why they sometimes need to use
__attribute__ ((packed)))

Technically the above link is a case for padding the end of a structure,
rather than between fields in a structure, but still of interest.

Can you produce a document that shows that ISO C of some flavour
guarantees to not pad structs in the way I've described?  The packed
attribute specifies that a variable or structure field should have the
smallest possible alignment, which seems to me to be exactly what we want
here.  Maybe it's unnecessary, but we should make sure of that before we
go breaking things, and if it's not tightly specified to be as you say,
I'd rather leave the packed directives in.  Given that the packed
directives (in lwip) are all macros that can easily be redefined by
anyone for whom it causes a problem, I think I've lost sight of what the
objection to them was.

Kieran