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

[Timmy Brolin]

Pedro Alves wrote:

> Timmy Brolin wrote:
>
> > Reading through the mailing list archive from two years ago refreshed 
> > my memory a bit.
> > For the Texas DSP+compiler the problem was that it do not support 
> > packed structs.
> > Several people had the same or similar problems related to unaligned 
> > fields in the structs.
> >
> > The 04/27/04 fix of bug #8708 solves all this by doing two things:
> > A 2 byte pad is added at the very beginning of the packet. This makes 
> > all the header fields problerly aligned, with one exception: The IP 
> > fields in the ARP header.
> > This is why ip_addr2 is there. By splitting the 32bit ip_addr into 
> > two 16bit fields all fields are properly aligned so that the packed 
> > struct attribute is no longer required for most compilers.
> > This solved the problem for everyone back then.
> > The 2 byte pad should actually improve performance a bit as well 
> > since it makes all the IP and TCP headers nice and aligned.
> >
> > I have to agree with you that the code must be fixed to comply with C 
> > standards. I guess memcpy is fine.
> > But replacing ip_addr2 with ip_addr will break things on all 
> > compilers that do not support packed structs. Possibly others as well.
> >
> > If your compiler generates special code to handle potential alignment 
> > problems whenever packed structs are used even if there are no 
> > alignment issues, then I suggest you try disabling packed structs. 
> > lwip in its current state should compile fine on most compilers even 
> > without packed structs.
> I went through the archives and read that discussion. I have better 
> understanding of struct ip_addr2 now. Thanks for the pointer.
> I say, go with memcpy then, and be done with it. The type punning was 
> my original concern.
> If struct ip_addr2 is kept, is there still a reason to have struct 
> ip_addr packed for compilers that do support packing?

Well, there was a long discussion about that two years ago. According to 
C standards adatatype may not have alignment requirements larger than 
its natural alignment, and padding may be introduced into structs to 
algin the fields in the struct. This would suggest that as long as we 
design the structs to be perfectly aligned, no compiler will add extra 
padding.
However, some ARM compilers (gcc arm is one of them) apears to align 
structs to a 32bit boundary, even if it does not contain any 32bit 
fields. So at least for some ARM compilers you may need packed structs 
for the ethernet header and the arp header.
The IP and TCP headers should be fine without packing even on ARM.

Regards,
Timmy Brolin