Hi Guy,
>> About the memory leak with g_renew, you're right of course.
>> "Unfortunately" there is no ep_realloc ... is there any reasons to /not/
>> implement one ? I've no idea of the complexity to implement one either ...
>>
>
> "realloc" is usually defined as to "allocate new, copy, free old" - and
> implementations might have an optimization, such that if there's enough
> free space after the existing item, it'll just be extended into that
> space, with no copy necessary.
>
thx for the clarification but ... I had no idea of the complexity of the
implementation in emem.c (with the optimization) ;)
> There's no "ep_free()" (by design), so "ep_realloc()" would be "allocate
> new, copy" - and I think that the optimization might be implementable,
> although it'd only work for the most recently allocated item.
>
That's another interesting question ... Is there a real interest to
implement an "optimization"? Wouldn't be always a "allocate new, copy"
+ a test on whether there is enough space after the existing item? Which
could be in practice slower than the "dumb" solution : always "allocate
new, copy".
> So, no, I don't see any reason not to implement ep_realloc()
We may start with the simplest solution "allocate new, copy". What do
you think of it?
Regards,
Sebastien Tandel
