On Wed, Apr 1, 2009 at 7:58 PM, Larry Hastings <la...@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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
