[Python-Dev] Let's update CObject API so it is safe and regular! (original) (raw)

Guido van Rossum guido at python.org
Thu Apr 2 05:51:55 CEST 2009

On Wed, Apr 1, 2009 at 7:58 PM, Larry Hastings <larry at hastings.org> wrote:

Guido van Rossum wrote:

Yeah, any two CAPI objects can be used to play this trick, as long as you have some place that calls them. :-( FWIW, I can't take credit for this observation.  Neal Norwitz threw me at this class of problem at the Py3k sprints in August 2007 at Google Mountain View, specifically with curses, though the approach he suggested then was removing the CObjects.  Then, Monday night MvL and I re-established the problem based on my dim memories.

So what's your solution? If it was me I'd change the API to put the full module name and variable name of the object inside the object and have the IMPORT call check that. Then you can only have crashes if some extension module cheats, and surely there are many other ways that C extensions can cheat, so that doesn't bother me. :) My proposed API requires that the creator of the CObject pass in a "type" string, which must be of nonzero length, and the caller must pass in a matching string.  I figured that was easy to get right and sufficient for "consenting adults".

OK, my proposal would be to agree on the value of this string too: "module.variable".

Note also this cheap exported-vtable hack isn't the only use of CObjects; for example ctypes uses them to wrap plenty of one-off objects which are never set as attributes of the ctypes module.  We'd like a solution that enforces some safety for those too, without creating spurious module attributes.

Why would you care about safety for ctypes? It's about as unsafe as it gets anyway. Coredump emptor I say.

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

More information about the Python-Dev mailing list