[Python-3000] cleaning up different ways to free an object

[Neal Norwitz]

On 8/19/07, Brett Cannon <brett at python.org> wrote:
> On 8/19/07, Neal Norwitz <nnorwitz at gmail.com> wrote:
> > I just fixed a bug in the new memoryview that used PyObject_DEL which
> > caused a problem in debug mode.  I had to change it to a Py_DECREF.
> > It seems we have a lot of spellings of ways to free an object and I
> > wonder if there are more problems lurking in there.
> >
> > $ cat */*.c | grep -c PyObject_Del
> > 103
> > $ cat */*.c | grep -c PyObject_DEL
> > 16
> > $ cat */*.c | grep -c PyObject_Free
> > 16
> > $ cat */*.c | grep -c PyObject_FREE
> > 19
> >
> > I don't know how many of these are correct or incorrect.
> >
> > Note in Include/objimpl, the Del and Free variants are the same.  I
> > plan to get rid of one of them.
> >
> > #define PyObject_Del            PyObject_Free
> > #define PyObject_DEL            PyObject_FREE
> >
> > PyObject_{MALLOC,REALLOC,FREE} depend upon whether python is compiled
> > with debug mode, pymalloc, or not.
> >
> > What are the rules for when a particular API should be used (or not
> > used) to free an object?
>
> If you read the comment at the top of Include/objimpl.h, it says that
> PyObject_(New|NewVar|Del) are for object allocation while
> PyObject_(Malloc|Realloc|Free) are just like malloc/free, but they use
> pymalloc instead of the system malloc.

Ya, I'm not talking about the distinctions/categories.  They makes
sense.  The 'correctness' I was referring to (thus the rules) was when
to use PyObject_Del vs Py_DECREF (ie, the problem with memoryview).  I
was trying to point out with the greps that the DELs/FREEs were
infrequently used.  I know there are some cases in _bsddb.c and I'm
wondering if those are correct (there are a handful of other modules
which also use them).  The Del variants are used more in Modules while
the Free variants are used more in the core.

Changing PyObject_Del to Py_DECREF may require that more of a
structure needs to be initialized before DECREFing, otherwise the
dealloc might access uninitialized memory.

I guess I can't really get rid of the aliases though, not without
making the API inconsistent.

> After that there are the usual performance macros.

Another thing that kinda bugs me is that the 'macro' versions are not
normally macros.  In a default build (ie, with pymalloc), they are
non-inlined function calls.

n