Douglas Pratley wrote: > We went through upgrades from MSCV 6 -> 7.1 -> 8 in my last job. The > only real problem we ran into (apart from all the code tweaks in the C++ > to make it compile 6 -> 7.1, which is not relevant here) was in passing > dynamically allocated memory across binary boundaries. > What do you mean by binary boundaries? DLLs I guess?
This should only be a problem if you alloc some memory in one DLL and free it in another (which is often a "hint" for a bad design anyway) - I would think that WS already do it that way (there might be some places left over to cleanup in this regard). AFAIK, given the limitation from above, you can USE that memory in any DLL instances of the program you like. > If everyone has followed the guidelines and used the "g_" functions for > allocation and deallocation, then all memory should be being allocated > from one CRT, so it may well just all "work". Would it be worth checking > the code to make sure that it doesn't use other allocation functions > anywhere? > There are three mechanisms I know of: - g_... throughout the "main" WS code - emem uses g_ and VirtualAlloc - some (generated?) dissectors uses malloc (at least a MSVC warning of a missing declaration seems to indicate this) All WS code will hopefully free the memory in the way it was alloced, so this shouldn't be such a big problem. > Of course, any bugs that occur if it doesn't just work will be > intermittent, awkward to find and fatal (or a security risk) if they do > occur... > There's one thing even more annoying: FILE "handles" are not "portable" across DLL's as the CRT keeps some "private" information about the files state, which is not "spreaded" between different CRTs. This was already discussed before on the list, maybe there are other CRT things to think about - the zlib is the biggest problem here. Fortunately, if we use the GLib stuff everywhere, "only" the remaining native C runtime calls have to be thought about ;-) Regards, ULFL _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
