ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Sebastien Tandel <sebastien@xxxxxxxxx>
Date: Sun, 11 Mar 2007 21:54:01 +0100
>>
>>    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.
>   

That's true but, anyway, having a ep_realloc could be interesting simply
for the coherence with existing memory allocation libraries. Even if it
only does "allocate new, copy". (without speaking of potential user's
bugs :))

>> 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
>>
>>     
>
>
>