<p dir="ltr"><br>
On 13 Jun 2013 10:09, "Victor Stinner" <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
><br>
> 2013/6/13 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>>:<br>
> > On 13 Jun 2013 09:09, "Victor Stinner" <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
> >> Using this patch, detecting memory corruptions (buffer underflow and<br>
> >> overflow) can be done without recompilation. We may add an environment<br>
> >> variable to enable Python debug functions at runtime, example:<br>
> >> PYDEBUGMALLOC=1. There is just a restriction: the environment variable<br>
> >> would not be ignored with -E command line option, because command line<br>
> >> options are parsed after the first memory allocation. What do you<br>
> >> think?<br>
> ><br>
> > The rest of it sounds fine, but please don't add the runtime switching<br>
> > support to our existing main function. Interpreter startup is a mess<br>
> > already. If you were interested in helping directly with PEP 432, though,<br>
> > that would be good - I haven't been able to spend much time on it lately.<br>
><br>
> I proposed an environment variable to solve the following issue: when<br>
> memory allocators are replaced with custom allocators, debug hooks<br>
> cannot be used. Debug hooks must be set before the first memory<br>
> allocation.<br>
><br>
> Another option is to add a new function (ex: PyMem_SetDebugHook()) to<br>
> install explicitly debug hooks, so it can be called after<br>
> PyMem_SetAllocators() and before the first memory allocation.</p>
<p dir="ltr">Yes, that sounds better. One of the biggest problems with the current startup sequence is the way it relies on environment variables for configuration, which makes life hard for other applications that want to embed the CPython runtime.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Victor<br>
</p>