Wireshark · Wireshark-dev: Re: [Wireshark-dev] [PATCH][UPDATE] ptvcursor : one step further?

[Sebastien Tandel <sebastien@xxxxxxxxx>]

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