(original) (raw)
On 22 November 2017 at 21:12, Victor Stinner <victor.stinner@gmail.com> wrote:
It does place some additional constraints on us in terms of handling static initialization of the allocator state, and ensuring we revert back to that state in Py\_Finalize, but I think it's the only way we're going to be able to reliably replace all calls to malloc & free with PyMem\_RawMalloc and PyMem\_RawFree without causing weird problems.
2017-11-22 12:04 GMT+01:00 Antoine Pitrou <solipsis@pitrou.net>:
\> IMHO this really needs a simple solution documented somewhere. Also,
\> hopefully when you do the wrong thing, you get a clear error message to
\> know how to fix your code?
Right now, calling PyMem\_RawMalloc() before calling
\_PyRuntime\_Initialize() calls the function at address NULL, so you get
a segmentation fault.
Documenting the new requirements is part of the discussion, it's one
option how to fix this issue.
My own recommendation is that we add Eric's new test case to the embedding test suite and just make sure it works:
wchar\_t \*program = Py\_DecodeLocale("spam", NULL);
Py\_SetProgramName(program);
Py\_Initialize();
Py\_Finalize();
PyMem\_RawFree(program);
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia