In the section on the "Very High Level Layer", address concerns brought up

by Edward K. Ream <edream@users.sourceforge.net> about FILE* values and
incompatible C libraries in dynamically linked extensions.  It is not clear
(to me) how realistic the issue is, but it is better documented than not.

This closes SourceForge bug #111520.
This commit is contained in:
Fred Drake 2000-08-14 02:50:21 +00:00
parent b07cf5080f
commit 510d08bfe4
1 changed files with 9 additions and 0 deletions

View File

@ -597,6 +597,15 @@ parameter. The available start symbols are \constant{Py_eval_input},
\constant{Py_file_input}, and \constant{Py_single_input}. These are \constant{Py_file_input}, and \constant{Py_single_input}. These are
described following the functions which accept them as parameters. described following the functions which accept them as parameters.
Note also that several of these functions take \ctype{FILE*}
parameters. On particular issue which needs to be handled carefully
is that the \ctype{FILE} structure for different C libraries can be
different and incompatible. Under Windows (at least), it is possible
for dynamically linked extensions to actually use different libraries,
so care should be taken that \ctype{FILE*} parameters are only passed
to these functions if it is certain that they were created by the same
library that the Python runtime is using.
\begin{cfuncdesc}{int}{PyRun_AnyFile}{FILE *fp, char *filename} \begin{cfuncdesc}{int}{PyRun_AnyFile}{FILE *fp, char *filename}
If \var{fp} refers to a file associated with an interactive device If \var{fp} refers to a file associated with an interactive device
(console or terminal input or \UNIX{} pseudo-terminal), return the (console or terminal input or \UNIX{} pseudo-terminal), return the