extension mixes MSVC & mingw32 stdio (was: Re: Building extensions with mingw32 -- bdist_wininst fails.)

[John Machin]

Pierre Schnizer <P.Schnizer at nospam.gsi.de> wrote in message news:<87adak1vez.fsf at smtp.gsi.de>...
> "Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> writes:
> 
> > ----- Original Message -----
> > From: "Thomas Heller" <theller at python.net>
> > 
> > > > I checked the archives regarding that error message and
> > > > found a conversation wherein Jeremy Hylton claimed he
> > > > might have added the code to detect this, and Paul Moore
> > > > asked to have it removed/disabled at least for mingw32
> > > > (which makes binaries 100% compatible with MSVC6).  In
> > > > the case given then, the extension wouldn't build at
> > > > all; now it builds but I can't make a Windows installer
> > > > from it.
> 
> Please excuse, if it is a bit out topic. 

You're excused.

> When I tried to build an extension module for Python2.2 with MingW3.0 I had
> problems with the conversion of files. So
> 
> myfile = PyFile_AsFile(object);
> 
> would crash python2.2 when a standard Python2.2 was invoking an extension
> module compiled with MinGW.
> 

If Python is compiled with compiler X, and an extension is compiled
with compiler Y, there is a very high chance that the runtime support
for files is quite different. What X's FILE* points to will be
different to what Y's FILE* points to.

Although MinGW uses the MSVC runtime msvcrt.dll, it's not the sort of
thing you should bet your last dollar on. For portability, always
assume that X != Y.

So, either (1) get a filename from the Python caller, and fopen it
yourself, and use stdio functions on the FILE* or (2) get a
PyFileObject* from the Python caller, and use the high-level API
functions on that e.g. PyFile_GetLine, PyFile_WriteString [not useful
if you have embedded '\0' in your string], PyFile_WriteObject.

IMHO, PyFile_AsFile() and PyFile_FromFile() should have severe
warnings in the documentation.

Hope this helps,
John