Wireshark mailing list archives
Re: emem -> wmem conversion status and next steps
From: Evan Huus <eapache () gmail com>
Date: Sat, 21 Sep 2013 14:09:13 -0400
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.quantin () 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 <eapache () gmail com> a écrit :On 2013-09-20, at 5:55 PM, Pascal Quantin <pascal.quantin () 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-request () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe
Current thread:
- emem -> wmem conversion status and next steps Pascal Quantin (Sep 20)
- Re: emem -> wmem conversion status and next steps Evan Huus (Sep 20)
- Re: emem -> wmem conversion status and next steps Guy Harris (Sep 20)
- Re: emem -> wmem conversion status and next steps Pascal Quantin (Sep 21)
- Re: emem -> wmem conversion status and next steps Evan Huus (Sep 21)
- Re: emem -> wmem conversion status and next steps Pascal Quantin (Sep 22)
- Re: emem -> wmem conversion status and next steps Evan Huus (Sep 22)
- Re: emem -> wmem conversion status and next steps Evan Huus (Sep 20)