On Sun, Oct 28, 2012 at 2:40 AM, Ken Chen <zlchen....@gmail.com> wrote: > Yes, I agree writing a corresponding API to free the memory is the best > practice and best bet. > Sometimes, the third party API may not provide that.
Then that's a majorly dangerous third party API. The only time it's safe to provide a half-only API like that is when the code gets statically linked with the application, so there's a guarantee that malloc() in one place corresponds to free() in another. > After digging the Python manual again and again. > I finally figure out why windll.msvcrt.free is failing. > > As the manual stated below, the DLL is using another version of msvcrt lib > which is different than the builtin windll.msvcrt. After I explicitly load > the msvcrt which built the DLL, things are getting function now. That's still vulnerable. There's really no guarantee about _anything_ with mismatched memory allocators; it's theoretically possible for compiler switches to change the behaviour of malloc/free such that compiling malloc in debug mode and free in release mode would crash your program. (I don't know off-hand of any compilers/libraries that do that specifically, but there are similar changes done in other ways.) If a DLL allocates memory and doesn't deallocate it, lean on its author to complete the job. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
