On Sun, Sep 22, 2013 at 11:56 AM, Pascal Quantin
wrote:
> 2013/9/21 Evan Huus
>>
>> The move from emem to wmem is already breaking compatibility in a
>> significant way (especially as we remove more and more emem functions
>> completely), and the current trunk is probably a good place to break
>>
2013/9/21 Evan Huus
> The move from emem to wmem is already breaking compatibility in a
> significant way (especially as we remove more and more emem functions
> completely), and the current trunk is probably a good place to break
> compatibility: it already contains the expert-info API change, a
The move from emem to wmem is already breaking compatibility in a
significant way (especially as we remove more and more emem functions
completely), and the current trunk is probably a good place to break
compatibility: it already contains the expert-info API change, and if
the next release is 2.0
Hi Evan,
I started locally converting tvbuff.h functions (I hope to finish the first set
tomorrow). For ex tvb_memcpy is now a define for wmem_tvb_memcpy(NULL, ...) and
ep_tvb_memcpy is a define for wmem_tvb_memcpy(wmem_packet_scope(), ...) so as
to maintain backward compatibility with external
On Sep 20, 2013, at 3:16 PM, Evan Huus wrote:
> I was hoping (at least for functions with both an ep and se version) to make
> the pool a parameter, so for example
>
> tvb_get_string(pool, ...)
+1
___
Sent via:Wiresha
On 2013-09-20, at 5:55 PM, Pascal Quantin wrote:
> Hi all,
>
> the easy part of the conversion from emem to wmem memory should be almost
> complete now: dissectors and plugins use the new memory manager (with the
> exception of uat / initialization routines).
>
> Next, I was thinking about co
Hi all,
the easy part of the conversion from emem to wmem memory should be almost
complete now: dissectors and plugins use the new memory manager (with the
exception of uat / initialization routines).
Next, I was thinking about converting our helper functions found in epan
module and the various
