[Swig-user] How to receive a FILE* from Python under MinGW?
john.pye at student.unsw.edu.au
Wed Mar 21 04:46:03 CET 2007
I'm not sure that your snippet really solves my problem. As far as I can
see from, you're just passing a filename instead of a file pointer,
right? And then you're using the Python fopen-equivalent
(PyFile_FromString) This is not an option for me, as I want to pass the
FILE* from Python and all the way into into a existing shared-library
code. I can't change the latter; it must work ok with standard fprintf
If I've missed something, perhaps you could clarify a little bit more on
how it is that you're overcoming the FILE* problem?
Carl Douglas wrote:
> Hi John,
> I had exactly this problem... use the PyFile_AsFile function. Below
> is a code snippet from my project:
> // Thank you: http://www.ragestorm.net/tutorial?id=21#8
> PyObject* PyFileObject = PyFile_FromString(ofn.lpstrFile, "r");
> if (PyFileObject == NULL)
> return false;
> // Because microsoft C runtimes are not binary compatible, we
> // just call fopen to get a FILE * and pass that FILE * to
> another application
> // or library (Python25.dll in this case) that uses a
> different version
> // of the C runtime that this DLL uses. Using PyFile_AsFile is a
> if (PyRun_SimpleFile(PyFile_AsFile(PyFileObject),
> ofn.lpstrFile) == -1)
> For the full source of my SWIG/Python project, poke around here:
> Hope that helps.
> On 3/21/07, John Pye <john.pye at student.unsw.edu.au> wrote:
>> Hi all
>> There is fairly well-known problem on MinGW with passing FILE pointers
>> to Python. The problem seems to be that Python depends on a different
>> version of msvcrt*.dll to that which MinGW depends on, and these
>> different C runtimes provide different FILE implementations.
>> The upshot of that seems to be that file objects created in Python via
>> the 'file(...)' command can't safely be used in a SWIG module. It can be
>> done perfectly (using SWIG typemap and PyFile_AsFile) on Linux but it
>> fails with a segfault on Windows.
>> What is the best possible workaround for this? Surely someone must have
>> found a satisfactory solution to this problem?
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia
More information about the Python-list