[Python-Dev] are CObjects inherently unsafe? (original) (raw)

Michael Hudson 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 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 PyCObjectImport(), 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 PyCObjectImportEx(), 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, PyCObjectImportEx() 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...

Cheers, mwh

-- 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 mailing list