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