On 3/11/07, Sebastien Tandel <sebastien@xxxxxxxxx> wrote:
Hi Jeff,
Thanx for reviewing it ... I had forgot about this one :)
I will write the README section soon.
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 ...
There's no need, just ep_alloc another block, and memcpy over it. It's
going to be "freed" before the next packet anyway.
Regards,
Sebastien Tandel
Jeff Morriss wrote:
> Sebastien Tandel wrote:
>
>> Hi,
>>
>> I've updated the patch for ptvcursor taking into account the ideas of Guy.
>>
>> Features supported by ptvcursor :
>> - multiple levels (256 max.), allocation per 8 levels.
>> - Two new functions creating an item in the tree and pushing a subtree at the same time. These two functions accept an undefined length (SUBTREE_UNDEFINED_LENGTH). The length of the item is set once the subtree is pop'ed.
>> 1) ptvcursor_add_with_subtree
>> 2) ptvcursor_add_text_with_subtree
>>
>>
>> If it sounds good I'll do a section for the README.developer.
>>
>
> Well, it looks OK to my (simple) eyes.
>
> One thing looks wrong to me, though: using g_renew() to malloc memory
> but there are also DISSECTOR_ASSERT()s in the code. If the assertion is
> taken dissection of that packet will stop and the memory will be leaked.
>
> Shouldn't that be changed to ep_ malloc'd memory?
>
> Unless anyone else has comments, could you write that README.developer
> patch, too?
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan