[Python-Dev] #ifdef __cplusplus?

Adam Olsen rhamph at gmail.com
Sat Jan 3 04:15:20 CET 2009

On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2009-01-02 08:26, Adam Olsen wrote:
>> Python's malloc wrappers are pretty messy.  Of your examples, only
>> unicode->str isn't obvious what the result is, as the rest are local
>> to that function.  Even that is obvious when you glance at the line
>> above, where the size is calculated using sizeof(Py_UNICODE).
>> If you're concerned about correctness then you'd do better eliminating
>> the redundant malloc wrappers and giving them names that directly
>> match what they can be used for.
> ??? Please read the comments in pymem.h and objimpl.h.

I count 7 versions of malloc.  Despite the names, none of them are
specific to PyObjects.  It's pretty much impossible to know what
different ones do without a great deal of experience.

Only very specialized uses need to allocate PyObjects directly anyway.
 Normally PyObject_{New,NewVar,GC_New,GC_NewVar} are better.

>> If the size calculation bothers you you could include the semantics of
>> the PyMem_New() API, which includes the cast you want.  I've no
>> opposition to including casts in a single place like that (and it
>> would catch errors even with C compilation).
> You should always use PyMem_NEW() (capital letters), if you ever
> intend to benefit from the memory allocation debug facilities
> in the Python memory allocation interfaces.

I don't see why such debugging should require a full recompile, rather
than having a hook inside the PyMem_Malloc (or even providing a
different PyMem_Malloc).

> The difference between using the _NEW() macros and the _MALLOC()
> macros is that the first apply overflow checking for you. However,
> the added overhead only makes sense if these overflow haven't
> already been applied elsewhere.

They provide assertions.  There's no overflow checking in release builds.

Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list