[Python-Dev] are CObjects inherently unsafe?

[Jim Fulton]

Michael Hudson wrote:
> Jim Fulton <jim at zope.com> writes:
> 
> 
>> > (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.
> 
> 
> The desc field in a CObject.
> 
> 
>>I don't really remember what the description was for. I also
>>don't have the original email.
> 
> 
> http://mail.python.org/pipermail/python-dev/2003-December/040702.html
> 
> 
>>>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. :)
> 
> 
> Good :-)
> 
> 
>> > 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.
> 
> 
> I feel a retcon coming on.
> 
> 
>>>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.
> 
> 
> Right.  What should we use as the description object?  A good old C
> string? 

Probably.  I don't have a strong opinion on it.

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