Re: ODP: [lwip-devel] [bug #26273] etharp.c : fix alignment issuein etharp_raw

[address@hidden]

Małowidzki wrote:
> I completely agree with that.
>
> Additionally, how could a compiler properly align addresses that are 
> dynamically computed, e.g., provided as a function's argument?
>   
They *are* properly aligned: the struct in question includes 2 u16_t 
elements! The question is why does the compiler translate an operator= 
of such a struct into a load/store u32_t?
> [..]
> then either sipaddr or dipaddr is not four-byte aligned (MAC addresses are 6-byte long). 
It does not have to be 4-byte-aligned but 2-byte-aligned, note the 
struct ip_addr2 (!2!) in struct etharp_hdr!
> The question appears, how the statement
>  
> hdr->dipaddr = hdr->sipaddr;
>  
> (struct to struct copy) is translated by a compiler. I believe that - if the alignement cannot be determined at a compile time - it should be translated (compiled) as a byte-by-byte memory copy (memcpy()).
I don't think so: it can rely on structs always being aligned, unless 
they are marked as packed.


Simon