> (Looking at PyObject_GenericGetAttr with that in mind, I wonder if > there isn't a possible crash there. In the first MRO lookup, looking > for descr's, if a non-data-descr is found, it is kept around but not > INCREF'd until later, after the instance-dict is searched. Am I > wrong in believing the PyDict_GetItem of the instance dict can call > Python code ? It can, if there's a key whose type has a custom __eq__ or __cmp__. So indeed, if this custom __eq__ is evil enough to delete the corresponding key from the class dict, it could cause descr to point to freed memory. I won't try to construct a case, but it's not impossible. :-( Fixing this would make the code even hairier though... :-( > There isn't even as much as an assert(PyDict_Check(dict)) there.) All over the place it is assumed and ensured that a types tp_dict and an instance's __dict__ are always real dicts. The only way this could be violated would be by C code defining a type that violates this. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4