[Python-Dev] #ifdef __cplusplus?

[Adam Olsen]

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