.. index:: object: file
These APIs are a minimal emulation of the Python 2 C API for built-in file
-objects, which used to rely on the buffered I/O (:c:type:`FILE*`) support
+objects, which used to rely on the buffered I/O (:c:expr:`FILE*`) support
from the C standard library. In Python 3, files and streams use the new
:mod:`io` module, which defines several layers over the low-level unbuffered
I/O of the operating system. The functions described below are
.. c:function:: long PyMarshal_ReadLongFromFile(FILE *file)
- Return a C :c:type:`long` from the data stream in a :c:type:`FILE*` opened
+ Return a C :c:type:`long` from the data stream in a :c:expr:`FILE*` opened
for reading. Only a 32-bit value can be read in using this function,
regardless of the native size of :c:type:`long`.
.. c:function:: int PyMarshal_ReadShortFromFile(FILE *file)
- Return a C :c:type:`short` from the data stream in a :c:type:`FILE*` opened
+ Return a C :c:type:`short` from the data stream in a :c:expr:`FILE*` opened
for reading. Only a 16-bit value can be read in using this function,
regardless of the native size of :c:type:`short`.
.. c:function:: PyObject* PyMarshal_ReadObjectFromFile(FILE *file)
- Return a Python object from the data stream in a :c:type:`FILE*` opened for
+ Return a Python object from the data stream in a :c:expr:`FILE*` opened for
reading.
On error, sets the appropriate exception (:exc:`EOFError`, :exc:`ValueError`
.. c:function:: PyObject* PyMarshal_ReadLastObjectFromFile(FILE *file)
- Return a Python object from the data stream in a :c:type:`FILE*` opened for
+ Return a Python object from the data stream in a :c:expr:`FILE*` opened for
reading. Unlike :c:func:`PyMarshal_ReadObjectFromFile`, this function
assumes that no further objects will be read from the file, allowing it to
aggressively load file data into memory so that the de-serialization can
:const:`Py_file_input`, and :const:`Py_single_input`. These are described
following the functions which accept them as parameters.
-Note also that several of these functions take :c:type:`FILE*` parameters. One
-particular issue which needs to be handled carefully is that the :c:type:`FILE`
+Note also that several of these functions take :c:expr:`FILE*` parameters. One
+particular issue which needs to be handled carefully is that the :c:expr:`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 :c:type:`FILE*` parameters
+use different libraries, so care should be taken that :c:expr:`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.