lwip-devel
[Top][All Lists]
Advanced

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

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


From: Stephane Lesage
Subject: [lwip-devel] [bug #27352] Change ip_addr from struct to typedef (u32_t)
Date: Sun, 07 Feb 2010 23:34:14 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

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

Hi again,
well maybe my last messages should go to a new thread about general
optimization, but a part of it is actually linked to the ip_addr_t type
definition.

Summary:
- we want to stick to passing addresses for the necessary evolution to dual
v4/v6 stack.
- we want to remove the packing from the ip_addr_t when it's stored in local
variables or PCB, and we can still use packing when using it as a field of
protocol headers. So a copy would be necessary sometimes.

My POV:
- I use sockets only and ip_addr.h contains useful macros/functions operating
only on ip_addr_t. As a new user, this was confusing and I still have to cast
pointers.
- in macros, we want to access individual octets.
- sometime we could copy the two u16_t instead of calling SMEMCPY for 4
bytes...
- I think removing packing is necessary but now I don't think changing
ip_addr_t to u32_t is good, because storing addresses in u32_t is often
associated to host byte order (IP_XXX / IN_xxx macros).

What I propose:
Define ip_addr_t to / use only:

struct in_addr {
  union {
    u32_t s_addr;
    struct { u16_t s_w1, s_w2; };
    struct { u8_t s_b1, s_b2, s_b3, s_b4; };
  };
};

BTW, ip_addr_set should be use only for safe copy, the latest modifications
use it everywhere, even if we don't have to check the pointer.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/





reply via email to

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