Re: [lwip-users] [PATCH] fix warning for gcc and possible unaligned access

[Timmy Brolin]

Leon Woestenberg wrote:

> As Curt mentions, this will surely be sub-optimal, but worst case is
> still doing everything run time, AFAICS.
>
> If we can do better, I would like to hear.
>
> Regards,
>
> Leon.
>  
I think the current arrangement is probably the best tradeoff there is.
The two byte padding at the beginning of the ethernet header struct in 
combination with ip_addr2 made sure that the lwip code never accesses a 
datatype on a alignment less than its natural alignment.
When it comes to the packing of structs there is plenty of flexibility. 
People with compilers which insert more padding than actually neccessary 
to reach natural alignment can use packing directives to get around that 
problem. Others can choose to not use the packing directives.
Some compilers may generate sub-optimal code when using packing 
directives, but if the same compilers also inserts more padding than 
required to get natural alignment of nested structs, then I only see a 
few options to get that to work in code: 1: Use packing. 2: Replace 
structs with arrays of U16s. 3: Don't use nested structs.
I doubt option 2 would be much more efficient than option 1, and it 
would make the code unreadable.
Option 3 should work, but I think someone said there is a reason ip_addr 
and ip_addr2 are structs rather than simply U32. I can't remember the 
reason at the moment.

There might be a fourth option in some cases.. There may be a command 
line option for some of the ARM compilers to not align nested structs on 
a 32bit alignment. If there is, then packing would not be neccessary.

Regards,
Timmy Brolin