[Python-Dev] #ifdef __cplusplus? (original) (raw)

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(PyUNICODE).

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 PyMemNew() 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 PyMemNEW() (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