Jakub, sorry about the global variable. The recent work on packet-dtn.[ch] comes from me. I read all the wireshark developer info prior to diving in, but I admit I don't recall any particular discussion of this. As you can see from [1], there were a great many global variables in there prior to my work. I just assumed that was the way to do it, and yet I still agonized over how to most effectively get the "bundle_custodian" variable into the code. I agree that global variables are to be avoided.
Do you have particular suggestions? Are some of the global variables here "less offensive" than others? Jim Jim Wright BioServe Space Technologies [email protected]<mailto:[email protected]> 303-492-1579 On May 8, 2012, at 4:26 PM, Jakub Zawadzki wrote: Hi, What's current policy of using global variables in dissectors? Some time ago I've fixed some issues connected with storing ep_ memory in global variables: r42002, r42005, r42008 and prepared patch for bug #7060 And I'm *really* not happy when we add it, like recent commit to packet-dtn.c [1] This commit seems safe, but I'd prefer to ban using global variables to store any information about current dissection. AFAIK we also plan to have libwireshark thread-safe. We can use TLS support in glib (GStaticPrivate[2]) or what compilers offers like __thread in GCC[3] or __declspec(thread) in MSVC[4] or even mutex for whole protocol dissection but wouldn't be better to not use global variables? There's already packet_info structure which is always private for current dissection. The easiest fix would be to move all global variables to packet_info structure. Anyone against it? [1] http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-dtn.c?r1=42507&r2=42506&pathrev=42507 [2] http://developer.gnome.org/glib/2.30/glib-Threads.html#GStaticPrivate [3] http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html [4] http://msdn.microsoft.com/en-us/library/6yh4a9k1.aspx ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]<mailto:[email protected]>> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
