[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: address@hidden
Subject: Re: ODP: [lwip-devel] [bug #26273] etharp.c : fix alignment issuein etharp_raw
Date: Wed, 22 Apr 2009 18:12:02 +0200
User-agent: Thunderbird (Macintosh/20090302)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]