...
61 #ifndef mem_realloc
62 static void *mem_realloc(void *mem, mem_size_t size)
63 {
64 LWIP_UNUSED_ARG(size);
65 return mem;
66 }
67 #endif
to
41 #if MEM_LIBC_MALLOC
...
61 #ifndef mem_realloc
62 #define mem_realloc realloc
63 #endif
From the sound of it, this violates a critical constraint of lwIP and we should not be doing this though it begs the question as to why lwIP requires nonstandard behavior from realloc but can accept the standard behavior of the other allocation functions.
If I'm not mistaken, the call to pbuf_realloc you cite in ip_input is dealing with a pbuf from one of the pools. At least in my application, our system level realloc is called only for RAM pbufs, never for pool pbufs, so I believe the behavior is correct.
As for the performance impact, again, those other pbufs you mention are not RAM pbufs, but pool pbufs and are reallocated without an actual call to the system level realloc.
ks
On Thu, Feb 11, 2010 at 7:09 AM, Simon Goldschmidt
<address@hidden> wrote:
Follow-up Comment #2, patch #7088 (project lwip):
I do see problems here, for example in ip_input: at the start of the
function, iphdr is set to p->payload. That patch attached here reallocs the
pbuf but does *not* change all pointers that already point into p->payload!
There are certainly other places where this change will hurt. Also, I don't
think this change is really "lightweight": it leads to "realloc" using memcpy
for rx packets although this wouldn't be necessary.
I very strongly vote against this going in!! Instead, for such heap
implementations, mem_realloc should do nothing, as MEM_LIBC_MALLOC does!
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/