[Python-Dev] are CObjects inherently unsafe?
mwh at python.net
Mon Dec 8 05:30:06 EST 2003
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
> 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.
>> 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.
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? Seems sensible enough to me, but Greg Ewing seemed to have
some other use in mind for it...
6. The code definitely is not portable - it will produce incorrect
results if run from the surface of Mars.
-- James Bonfield, http://www.ioccc.org/2000/rince.hint
More information about the Python-Dev