lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] mem_realloc bug?


From: John C. Toman
Subject: [lwip-users] Re: [lwip] mem_realloc bug?
Date: Thu, 09 Jan 2003 00:50:27 -0000

Hi Adam,

I'd like to see the mem_realloc stuff #ifdef'd and selectable in 
lwipopts.h. I think this makes sense. I don't believe my application has 
much need of it, and I think the payoff during pbuf_realloc() calls 
isn't worth the code or time footprint. At least in my case on my 8-bit 
platform, that is. By the way, #ifdef ing this on the Rabbit platform 
saves 300 bytes of code ...

John

Adam Dunkels wrote:

>Hi!
>
>On Mon, 2002-08-05 at 20:33, Earle Clubb wrote:
>  
>
>>I noticed that if mem_realloc() in mem.c is called in an attempt to increase
>>the size of a given memory block, mem_realloc does nothing and returns no
>>errors.  Is this a bug or is it there by design?
>>    
>>
>
>It is there by design - it wasn't intended to be used to increase the
>memory allocation.
>
>  
>
>>1) Why doesn't mem_realloc have the capability to increase the size of a
>>memory block?
>>
>>2) Is there a reason why it should not be added?
>>    
>>
>
>The reason was quite simple; it wasn't needed for anything in the lwIP
>stack.
> 
>  
>
>>3) I believe that an error should be returned if mem_realloc cannot
>>accomodate the requested new size.
>>    
>>
>
>That probably would be a better way to handle it.
>
>Actually, I have been thinking about the necessity of the mem_realloc()
>function as it is very rarely used in lwIP. I suppose you are using it
>for something in your code - what is your oppinion about it?
>
>/adam
>  
>




[This message was sent through the lwip discussion list.]




reply via email to

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