[Python-Dev] are CObjects inherently unsafe?

Guido van Rossum guido at python.org
Fri Dec 5 09:41:20 EST 2003

> > Indeed, CObjects seem fundamentally dangerous to me, unless
> > the modules which create and use them are extremely careful
> > to make sure they can tell whether they've got the right
> > kind of CObject.
> Well, the right *CObject* -- it's CObject identity that matters.

I seem to recall that the CObject design contains a feature to avoid
using the wrong CObject, but it's not used by any of the CObject
implementations in the standard library, and the CObject docs don't
describe how it's meant to use (they were clearly reverse-engineered
from the code).

Several early checkin messages of cobject.c mention Jim Fulton as the
author, so maybe we could ask him.  (I'm cc'ing Jim in case he
remembers the true intention for the description; he might also know
whether Zope 2 still uses it; I can only check Zope 3, and it

But even without Jim's confirmation, ISTM from memory and looking at
the source that the 'desc' field (which stands for description) was
intended as a clue that could be checked by the user of a C Object to
verify it had gotten the right one: in a shared header (needed anyway
to describe the layout of the struct pointer contained in the C
Object) you could define a magic word or a magic string value that
would be stored as the description, and the users would check that
value before believing the struct pointer.

Unfortunately the same CObject version that introduced the description
field also introduced the convenience function PyCObject_Import(),
which doesn't return the description, and returns the void pointer
contained in the CObject without returning the CObject itself, leaving
its caller without a clue about the description...

Anyway, I think it can be fixed by starting to use the description
field and adding a new convenience C API, perhaps named
PyCObject_ImportEx(), whch takes a description and checks it.  We
should try to standardize on what kind of thing to use as the
description -- if we use a magic word, PyCObject_ImportEx() should do
a simple compare, but if we use a string, it should do a strcmp().  Or
the API could simply return the description into an output parameter,
making the caller responsible for doing the checking.

And the docs should be updated to explain the description better
(currently at one point the description is called "extra callback data
for the destructor function" which seems a rather odd feature).

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list