On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg <m...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
