<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 November 2017 at 21:12, Victor Stinner <span dir="ltr"><<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">2017-11-22 12:04 GMT+01:00 Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>>:<br>
> IMHO this really needs a simple solution documented somewhere.  Also,<br>
> hopefully when you do the wrong thing, you get a clear error message to<br>
> know how to fix your code?<br>
<br>
</span>Right now, calling PyMem_RawMalloc() before calling<br>
_PyRuntime_Initialize() calls the function at address NULL, so you get<br>
a segmentation fault.<br>
<br>
Documenting the new requirements is part of the discussion, it's one<br>
option how to fix this issue.<br></blockquote><div><br></div><div>My own recommendation is that we add Eric's new test case to the embedding test suite and just make sure it works:</div><div><pre>    wchar_t *program = Py_DecodeLocale("spam", NULL);
    Py_SetProgramName(program);
    Py_Initialize();
    Py_Finalize();
    PyMem_RawFree(program);
</pre></div>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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br></div><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>