[Python-bugs-list] [Bug #110821] On Windows, APIs passing FILE* break with Borland C (PR#121)
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 13 Sep 2000 03:53:52 -0700
Bug #110821, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.
Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)
Details: Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None
The system encountered a fatal error
After command:
Received:
The last error code was: Connection refused
Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug
{HYPERLINK "../python-bugs/"}Public interface
{HYPERLINK "../python-bugs.private"}Private interface (requires password)
{HYPERLINK "http://www.python.org/"}Python home page
-----
Here's what I said for Python 1.5.2 on Win32 #0
PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not
usable on WIN32 from non-VC applications because python15.dll is statically
linked to the MS runtime DLL. Embedding applications that try to use these
functions are passing in FILE * structures that do not match MS's runtime
format.
For example, I'm using Python in a Borland C++ Builder application. Although I
can open a FILE *, when passed to python15.dll the FILE * is not usable.
The addition of two helper functions would solve this problem:
FILE * PyRun_OpenFile(char *file, char *mode)
{
return fopen(file,mode)
}
int PyRun_CloseFile(FILE *ptr)
{
return fclose(ptr)
}
This way embedding apps could get python15.dll to open the file and it would
work.
A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..
Brad Clements, bkc@murkworks.com (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com ICQ: 14856937
====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999 guido moved from incoming to request
Follow-Ups:
Date: 2000-Aug-01 14:10
By: none
Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500
> I tried to post a bug, but got this error:
>
> The system encountered a fatal error
We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver. It
should be back on now.
> Here's what I said for Python 1.5.2 on Win32 #0
>
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not
> usable on WIN32 from non-VC applications because python15.dll is statically
> linked to the MS runtime DLL. Embedding applications that try to use these
> functions are passing in FILE * structures that do not match MS's runtime
> format.
>
> For example, I'm using Python in a Borland C++ Builder application. Although I
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
>
> The addition of two helper functions would solve this problem:
>
> FILE * PyRun_OpenFile(char *file, char *mode)
> {
> return fopen(file,mode)
> }
>
> int PyRun_CloseFile(FILE *ptr)
> {
> return fclose(ptr)
> }
>
> This way embedding apps could get python15.dll to open the file and it would
> work.
>
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..
This is an elegant solution. I think I'll add it.
Could you mail me your suggestion again with the legal boilerplate
included? See http://www.python.org/1.5/bugrelease.html for the text
and explanation. Our lawyers require that I request this silliness...
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------------------------------------------------
Date: 2000-Aug-01 14:10
By: none
Comment:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500
Here it is again.
Also, I believe this will resolve FAQ entry 8.10
> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think).
>
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument.
>
>
>
> ---------------------------------------------------------------------------
> -----
> Here's what I said for Python 1.5.2 on Win32 #0
>
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not
> usable on WIN32 from non-VC applications because python15.dll is statically
> linked to the MS runtime DLL. Embedding applications that try to use these
> functions are passing in FILE * structures that do not match MS's runtime
> format.
>
> For example, I'm using Python in a Borland C++ Builder application. Although I
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
>
> The addition of two helper functions would solve this problem:
>
> FILE * PyRun_OpenFile(char *file, char *mode)
> {
> return fopen(file,mode)
> }
>
> int PyRun_CloseFile(FILE *ptr)
> {
> return fclose(ptr)
> }
>
> This way embedding apps could get python15.dll to open the file and it would
> work.
>
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims"). To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.
I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation. I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.
Brad Clements, bkc@murkworks.com (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com ICQ: 14856937
-------------------------------------------------------
Date: 2000-Sep-07 15:01
By: jhylton
Comment:
Please do triage on this bug.
-------------------------------------------------------
Date: 2000-Sep-12 09:01
By: jhylton
Comment:
Guido -- In 1999, you said you would add this feature. Did you?
-------------------------------------------------------
Date: 2000-Sep-13 03:53
By: gvanrossum
Comment:
This is a feature request.
Jeremy, how's that feature request PEP coming?
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110821&group_id=5470