Paul Moore wrote:
So, the question is - is there really any problem with Python 2.4, built with MSVC7, using an extension DLL built with MSVC6?
Just try and see for yourself. I saw the omniORB IDL compiler crash because of that.
Memory allocation "should" be OK, if extension writers follow the rules in the Python/C API manual, section 9.1 - "To avoid memory corruption, extension writers should never try to operate on Python objects with the functions exported by the C library: malloc(), calloc(), realloc() and free()". And no-one ever writes extensions which violate the rules :-)
This is not sufficient. For example, using the s# argument parser means the extension module needs to call PyMem_Free on the resulting memory block, allocated by getargs. According to the documentation, the extension module can safely call PyMem_FREE instead, which would cause heap confusion.
So, a question - would it be worth documenting which APIs are *not* supported in extensions built with an incompatible CRT to the one Python was built with? And if this was done, would it be OK to state "if you don't use these APIs, you don't have to build your extension or embedding application with the same CRT as that of Python"?
I would not make such a statement. It is *never* OK to mix CRTs, even if one cannot construct a case where this causes problems. That said, people will be using other compilers to create extensions if they find it works for them. They need to perform their own testing, and once they are satisfied, they will ship the code no matter what the documentation says. Regards, Martin