[David Abrahams] > Someone I work with recently caused a test to start asserting in VC7's > instrumented free() call, using a pydebug build. He explained the > change this way: > > "I switched from PyObject_New to PyObject_NEW, which according to it's > documentation omits the check for type_object != 0 and consequently > should run a little bit faster" > > [he doesn't ever pass 0 as the typeobject] > Did he miss some other important fact about PyObject_NEW? Does the > doc need to be fixed? [Guido] > You can read the source code as well as I can. Possibly, but not as well as I can <wink> -- the memory API's implementation is monumentally convoluted, especially before 2.3. Speaking of which, David, which version of Python was "someone" using? Did they enable pymalloc? Did they give you a traceback (showing from where free() was called)? Was it even freeing a Python object at the time? In what code base did someone make this substitution (e.g., Python core, Boost sources, someone's own extension module, someone else's extension module)? The straight answer to your question is no. A nastier answer is that many memory mgmt screwups are shy, and can be triggered by seemingly irrelevant changes.
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