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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
