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:
parent
b07cf5080f
commit
510d08bfe4
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue