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

[Iordan Neshev]

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?

Iordan Neshev
Daisy Technology
www.daisytechbg.com