Experimental Physics and
Industrial Control System

Hi,

 

Ok, maybe an example might help. If you were using a library that exported an allocateSomeMemory() function then you would probably not be surprised if you called free() on some memory returned from this and got a crash, you are not guaranteed allocateSomeMemory() (or any pointers/objects returned from the library)  used malloc() and you need to call the appropriate freeSomeMemory() function (hopefully) provided by that library to deallocate safely.

 

On windows when you compile static/dll/debug/release this can lead to a different choice of malloc/free/new/delete (and also allocation of file descriptor functions) being embedded in the library. To be absolutely safe on windows you need to assume that any pointers to objects or resources returned from a third party library have been allocated by an unknown allocateSomeMemory() like function and you need to use the appropriate freeSomeMemory() or similar to deallocate it. If you compile all objects that share resources the same way, then they will all be using the same underlying C library functions and you do not get an issue. If you mix objects compiled with different CRTL flags within a library, then it might potentially work depending on which objects shared resources with each other, or you may instead get a link time error about multiply defined symbols as it tries to bring in two different versions of the C library each defining the same functions (you can sometimes work around this with the /NODEFAULTLIB linker flag)    

 

So in the example below if Com, ca, ezca, and EzcaScan and all built the same statically (/MT compiler flag) and linked together to form ezcaIDL.dll that will all work fine with the following proviso. If ezcaIDL.dll exports functions that return pointers to objects allocated within the library, then these objects will have used malloc etc. appropriate for the static /MT flag. If ezcaIDL.dll was linked/loaded into an application that had been compiled /MD (i.e. to use the dynamic CRTL) then it could happily use these objects/pointers returned by the ezcaIDL library, but it must not call free() etc on these pointers as it would call the wrong (/MD) version of the free function. If you needed a /MD compiled application to be able to able to call free() directly on such pointers, you would need to change /MT to /MD in the static compile for the components of ezcaIDL.dll  Note that in times gone by mixing code all compiled /MD but with different versions of visual studio also caused similar issues …

 

Regards,

 

Freddie