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 :) On Sat, Sep 21, 2013 at 1:57 PM, Pascal Quantin <pascal.quan...@gmail.com> wrote: > 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 dissectors / > plugins (I changed also all the function calls in our source tree). > I just saw the rename you did in r52164. While I understand the purpose I > think it is not a move in the right direction as it breaks backward > compatibility (and it collides with my changes but it's not the important > part ;) ). Would my proposal be an acceptable tradeoff instead? > > Cheers, > Pascal. > > Le 21 sept. 2013 à 00:16, Evan Huus <eapa...@gmail.com> a écrit : > >> On 2013-09-20, at 5:55 PM, Pascal Quantin <pascal.quan...@gmail.com> 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 converting our helper functions found in epan >>> module and the various ep_ and se_ functions. >>> My idea was to update (and rename!) those functions with the following >>> scheme: >>> tvb_get_ephemeral_string -> tvb_get_wmem_packet_string >>> tvb_get_seasonal_string -> tvb_get_wmem_file_string >>> and adding defines to maintain (temporarily?) backward compatibility: >>> #define tvb_get_ephemeral_string tvb_get_wmem_packet_string >>> #define tvb_get_seasonal_string tvb_get_wmem_file_string >>> >>> Of course we will discover some misuse of ep/se memory (like for uat) that >>> will require more thinking, but it would be one step forward. >> >> 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, ...) >> >> This can also replace the glib versions of such functions automatically by >> passing NULL as the pool (wmem provides this "for free"). >> >> The macros are a good idea. >> >>> Thoughts? >>> >>> Regards, >>> Pascal. >>> ___________________________________________________________________________ >>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>> Archives: http://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
