[lwip-devel] [bug #27352] Change ip_addr from struct to typedef (u32_t)

[Simon Goldschmidt]

Follow-up Comment #30, bug #27352 (project lwip):

> I get the folowing warning about everywhere:
> "taking the address of a misaligned field is not recommended"

At least that tells us that there are compilers that do warn about this.
However, most of the time, I'm developing under MS Visual Studio using the MS
cl.exe compiler. Given that the x86 platform supports unaligned pointers, this
compiler unfortunately does *not* warn me about using them. Although using
unaligned pointers decreases performance on this platform, as well.

I'll have to try the embedded compiler next week and see at which places we
have to copy the address onto the stack.

> - all packed structures seem to be fine with word alignment,

Most of them are, I guess, but not all. At least struct etharp_hdr contains
an unaligned IP address (sipaddr). This is currently the reason we have the
struct ip_addr2. However, if that's the only problem we can just add an u16_t
array there, since we only access this field using SMEMCPY, anyway.

If the incoming packets' IP headers are aligned correctly then indeed one
might try to disable packing completely. Only some structs would still require
packing (netbios and ip_reass_helper mainly).

> - define IP4_ADDR() and ip4_addrX() macros directly according to
endianness

On big endian platforms, the ntohX/htonX functions should be defined to
nothing, so that should improved away by the compiler.

> Also why not define the macros to work on values instead of pointers ???

Macros are not a problem here: they are evaluated in place and the compiler
should still know about packing. We only might have to avoid casting to an
ip_addr_t pointer in a macro.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/