On Sun, Sep 22, 2013 at 11:56 AM, Pascal Quantin
<pascal.quantin@xxxxxxxxx> wrote:
> 2013/9/21 Evan Huus <eapache@xxxxxxxxx>
>>
>> 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 (using Qt) then I would prefer to make a clean
>> break as much as possible. There will be no need to specify the wmem
>> in wmem_tvb_memdup when eventually there will be no other
>> tvb_memdup-family functions left.
>>
>> All that said, I don't have a particularly strong attachment to this
>> position. If the general consensus ends up being to call them all
>> wmem_ and keep the existing names as-is, I won't object :)
>
>
> Hi Evan,
>
> fair enough, it simplifies naming scheme a bit. I pushed in r52172 a first
> set of function conversion / rename related to tvbuff management:
> - ep_tvb_get_bits() -> wmem_packet_tvb_get_bits()
> - tvb_g_memdup()/ep_tvb_memdup() -> tvb_memdup()
> - tvb_fake_unicode()/tvb_get_ephemeral_faked_unicode() ->
> tvb_get_faked_unicode()
> - tvb_get_g_string()/tvb_get_ephemeral_string()/tvb_get_seasonal_string() ->
> tvb_get_string()
> - tvb_get_g_unicode_string()/tvb_get_ephemeral_unicode_string() ->
> tvb_get_unicode_string()
> - tvb_get_ephemeral_string_enc() -> tvb_get_string_enc()
> Almost all of them now take an allocator as first argument to define the
> kind of memory requested and it allows to reduce a bit the number of APIs.
> If other think that a (temporary?) backward compatibility is needed, it's
> still possible to rename those functions with a wmem_ prefix and add defines
> for the old functions.
>
> Cheers,
> Pascal.
This is excellent. Thank you!
