[lwip-devel] [bug #26273] etharp.c : fix alignment issue in etharp_raw

[Bill Auerbach]

Follow-up Comment #11, bug #26273 (project lwip):

>would it be possible to use the SMEMCPY alternative ?

The following will work for you and might be more efficient than memcpy
(SMEMCPY).

  hdr->sipaddr.addrw[0] = ((struct ip_addr2 *)ipsrc_addr)->addrw[0];
  hdr->sipaddr.addrw[1] = ((struct ip_addr2 *)ipsrc_addr)->addrw[1];
  hdr->dipaddr.addrw[0] = ((struct ip_addr2 *)ipdst_addr)->addrw[0];
  hdr->dipaddr.addrw[1] = ((struct ip_addr2 *)ipdst_addr)->addrw[1];

Because my compiler cannot determine the alignment it generated 2 calls to
memcpy to copy these 8 bytes.  Because of this, maybe the code above is better
for all?

Simon, is the original code bad because it can (does in my case) make a
memcpy function call?

I agree about changes to get around compiler bugs, but there's a lot to be
said about coding something simpler to avoid an unknown way the compiler will
handle something.  This could mean that all struct assignments are converted
to memcpy calls.  This is something I don't want to see - the runtime overhead
is enormous.

I'm inclined now to agree with you and Simon that the ST compiler is wrong -
it should have done a byte copy or called memcpy.  This bug for ST might only
present itself with packing enabled though (not that that helps you).

Should a task be considered for removing struct copies?  Not for the ST
compiler, but because of the memcpy calls that might (or might not) result?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26273>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/