Jack Jansen wrote:
>
> One point to think of, with the malloc cleanup: how many places are there
> where Python allocates something that is passed to some packages which then
> takes ownership of it (and ultimately free()s it)?
None that I know of.
> And the other way around?
>
One. PyOS_Readline, when the interpreter is compiled with the readline module.
(i.e when the PyOS_ReadlineFunctionPointer hook is activated, see myreadline.c)
Actually PyOS_Readline gets a malloc'ed chunk from the readline module which is
subsequently freed by Python. The right way to do it is to require that the
buffer passed to PyOS_Readline is allocated through PyMem_Malloc.
This should/will be documented, and is corrected in the patch.
The other way around would be wrong, i.e. Python should not release the incoming
buffer with free(). We can't know the malloc used on the other side, so it's not
our job to guess it. (think embedding apps)
Note that the 2 cases you're describing are bad design.
> For these cases we should probably continue to use malloc()/free() to be on
> the safe side.
For now, nobody will notice anything, because Python's malloc will default
to malloc/free. So we're still on the safe side. It's about preparing
the code to be able to switch core malloc, eventually, optionally.
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
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