Re: [lwip-devel] possible mistake in mem.h

[Jonathan Larmour]

I have submitted a patch: https://savannah.nongnu.org/patch/index.php?6414

Please try it out as I'm not in a position to. I think I've covered
everything discussed.

Jifl

Grubb, Jared wrote:
> That sounds very nice.
> Jared
> 
> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Goldschmidt Simon
> Sent: Thursday, January 31, 2008 01:19
> To: lwip-devel
> Subject: RE: [lwip-devel] possible mistake in mem.h
> 
> I can think of a third solution:
> 
> Use mem_size_t and define it to size_t when MEM_LIBC_MALLOC == 1 (because 
> when calling malloc() with a mem_size_t argument, I wouldn't sleep calm, 
> also! :-)
> 
> Simon
>  
> -----Ursprüngliche Nachricht-----
> Von: address@hidden [mailto:address@hidden Im Auftrag von Iordan Neshev
> Gesendet: Donnerstag, 31. Januar 2008 11:14
> An: address@hidden
> Betreff: [lwip-devel] Re: Re: possible mistake in mem.h
> 
> Simon wrote:
>> Iordan Neshev schrieb:
>>> void *mem_malloc(mem_size_t size);
>>> void *mem_calloc(size_t count, size_t size); //  mem_size_t???
>>>  
>> Hmm, this is a bug, indeed! But I'd rather solve this the other way
>> round: let the size parameter of mem_malloc be size_t, not mem_size_t.
>> The reason for that is that it is the same for both MEM_LIBC_MALLOC 
>> settings.
> We need to discuss this more.
> There is another function that uses mem_size_t - void *mem_realloc(void *mem, 
> mem_size_t size);
> 
> Searching all the project shows that mem_size_t is used only in mem.c, mem.h 
> and stats.h.
> 
> If you make mem_malloc to take size_t, then what about mem_realloc()? If you 
> modify it also to taka size_t, then
> (maybe) mem_size_t is no longer needed. In that case we should #include 
> <stddef.h> in mem.h
> 
> I really like the use of mem_size_t - I feel more powerful with it, I can 
> tweak the code to suit custom needs. I can save a little bit of memory. 
> Exactly how much - depends on the architecture and the compiler.
> 
> IMHO if we use only size_t, we loose.
> 
> So, we have to choose between:
> 1. #include <stddef.h> in mem.h, kill mem_size_t and hope that the compiler 
> defines size_t with suitable length.
> Every compiler could assume different lengths for size_t and this may lead to 
> unpredictable bugs in future. You never know what happens tomorrow.
> In this case we'll have to trouble our brains of the consequences of the 
> eventually changed behavior of stats functions. What you observe on your 
> target with your compiler may be different for other people. I told you I 
> have noticed some inconsistencies just by porting the msvc port to the target.
> 
> 2. Use mem_size_t for mem_malloc() and sleep calm.
> 
> 3. Cannot think of other solution. And you?


-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Visit us @ Embedded World 2008, Nürnberg, Germany, 26-28 Feb:Stand 11-336
------["Si fractum non sit, noli id reficere"]------       Opinions==mine