[Python-Dev] are CObjects inherently unsafe?

[Jim Fulton]

Guido van Rossum wrote:
>>>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. 

Yup, I'm the one who proposed CObject.

 > (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
> doesn't.)

What "it" are you refering to.

I don't really remember what the description was for. I also
don't have the original email.

> But even without Jim's confirmation, ISTM from memory and looking at
> the source that the 'desc' field (which stands for description)

I now hate abbreviations like that btw. :)

 > 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.

I vaguely remember that such a clue was one possible application
of the extra data.  I really imagined that the destructor could need the
extra data, but, again, it's been a long time.  Too bad there's not a PEP. :)

> 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...

That's because I don't think that the description was primarily intended
as a fingerprint.

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

I like the idea of adding this use of the description.  That is,
the description is really a marker, that is obtained from an include file
and checked against the value in the CObject.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org