18.11.17 02:01, Victor Stinner пише: > 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. Wouldn't be better to revert (the part of) global variables moving? I still don't see a benefit of it. > To give a more concrete example: Py_DecodeLocale() is the recommanded > function to decode bytes from the operating system, but this function > calls PyMem_RawMalloc() which does crash before > _PyRuntime_Initialize() is called. Is Py_DecodeLocale() used to > initialize Python? > > For example, "void Py_SetProgramName(wchar_t *);" expects a text > string, whereas main() gives argv as bytes. Calling > Py_SetProgramName() from argv requires to decode bytes... So use > Py_DecodeLocale()... > > Should we do something in Py_DecodeLocale()? Maybe crash if > _PyRuntime_Initialize() wasn't called yet? I think Py_DecodeLocale() should be usable before calling Py_Initialize(). In the example in Doc/extending/extending.rst it is used before Py_Initialize(). If the third-party code is based on this example, it will crash now.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4