On Mar 21, 3:15 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Wed, 21 Mar 2007 00:46:03 -0300, John Pye > <[EMAIL PROTECTED]> escribió: > > > 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 > > (etc) functions. > > You can get the file descriptor from the Python file object using its > fileno() method. The file descriptor lives at the OS level, so it's safe > to pass around. You can regenerate a new FILE struct (using the other > runtime library) with fdopen. > > -- > Gabriel Genellina
Hi Gabriel Are you sure about this? My understanding is that 'fileno' is just a FILE* cast to an integer. So it's a pointer to something (check out stdio.h to see what it points to). Problem is (AFAICT) that Python 2.4 uses a different version of the C runtime DLL (MSVCRT*.DLL) to that which MinGW links against. And it turns out that the different C runtime libraries have incompatible implementations of the FILE struct. And therefore if you try to pass a FILE* (fileno?) from Python to MinGW you will get a segfault. If there is more to your suggestion that I'm not seeing, please clarify. Have you tried this with MinGW actually? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
