On Thu, 23 Nov 2017 10:37:59 +0100 "M.-A. Lemburg" <m...@egenix.com> wrote: > On 18.11.2017 01:01, Victor Stinner wrote: > > Hi, > > > > The CPython internals evolved during Python 3.7 cycle. I would like to > > know if we broke the C API or not. > > > > Nick Coghlan and Eric Snow are working on cleaning up the Python > > initialization with the "on going" PEP 432: > > https://www.python.org/dev/peps/pep-0432/ > > > > Many global variables used by the "Python runtime" were move to a new > > single "_PyRuntime" variable (big structure made of sub-structures). > > See Include/internal/pystate.h. > > > > A side effect of moving variables from random files into header files > > is that it's not more possible to fully initialize _PyRuntime at > > "compilation time". For example, previously, it was possible to refer > > to local C function (functions declared with "static", so only visible > > in the current file). Now a new "initialization function" is required > > to must be called. > > > > In short, it means that using the "Python runtime" before it's > > initialized by _PyRuntime_Initialize() is now likely to crash. For > > example, calling PyMem_RawMalloc(), before calling > > _PyRuntime_Initialize(), now calls the function NULL: dereference a > > NULL pointer, and so immediately crash with a segmentation fault. > > To prevent a complete crash, would it be possible to initialize > the struct entries to a generic function (or set of such functions > with the right signatures), which then issue a message to stderr > hinting to the missing call to _PyRuntime_Initialize() > before terminating ?
+1. This sounds like a good idea. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
