[Python-Dev] Re: Python 2.4 and MSVC 7.1 - extension compatibility

[Paul Moore]

"Martin v. Löwis" <martin at v.loewis.de> writes:

> 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.

Hmm. In itself, that's not conclusive, as it's possible that omniORB
uses the "dangerous" APIs I mention below. But your other arguments
*are* sufficient, so having a specific example is very helpful. I've
seen too many "well, it seems to work OK for me" comments to be
entirely comfortable with the fact that I had managed to find no
evidence of crashes myself.

>> Memory allocation "should" be OK,

[...]

> 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.

OK. That's a documented usage which requires using the same C runtime.
It could be argued that the documentation could be changed to "tighten
up" the requirements, but that way lies madness :-)

>> 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.

Thanks. I guess my only reservation was that I wasn't 100% clear on
what constitutes "mixing", given that, for example, Python, built with
MSVC7, can load win32api.pyd (from win32all), built with MSVC7, which
uses oleaut32.dll (MS system file) which in turn uses msvcrt.dll. That
is expected to work, so we are, in some sense, not "mixing" CRTs in
this case.

I'm still not entirely clear, but I'm happy to accept your statement
on the matter.

> 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.

I know :-( And given the fact that there's nothing in a binary
distribution to make it obvious what compiler was used to build the
extension, there's the risk that binary distributions will be shipped
with subtle problems like this.

[Checks]

On the other hand, i've just seen that the (MSVC7) Python 2.4
distutils refuses to let me build an extension with MSVC 6. So maybe
things aren't as bad as all that - if you get a distutils-built
Windows binary, you can be pretty happy that it uses a compatible CRT.

Thanks for the comments. Most of this is quite probably FUD, and in
reality everything will go smoothly. I just shocked myself this
evening by going through my Python environment, and realising how many
binary extensions I rely on (many of which I don't have the facilities
to build for myself, even if I had the time...)

Paul.
-- 
This signature intentionally left blank