> [David Abrahams, on the Py_CLEAR macro] > > FWIW our experience in the C++ community suggests that > > deallocate-and-NULL tends to hide bugs. In general we prefer to use > > deallocate-and-fill-pointer-with-garbage. I'm not sure if the > > experience translates here, of course. [Tim] > I don't think so. Along with the macro, Jim checked in a nice > explanation in the Extending and Embedding manual. A decref can cause > anything to happen if the decref'ed containee is now trash, including > fresh accesses to the container object holding the now-trash containee > that was decrefed. If the container's pointer to the containee isn't > NULLed out first, the entire implementation of the container has to be > aware that this particular containee may hold an insane value. Ditto > if garbage is put in the pointer. Ditto for NULL too, but NULL is a > single, obvious, and easy-to-test way to say "and this containee no > longer exists". This isn't really so much about deallocation as about > horrid side effects triggered by deallocation. Plus, in many cases NULL is *already* an expected value. We even have macros like Py_XDECREF() that are NULL-aware. --Guido van Rossum (home page: http://www.python.org/~guido/) --i6G2WKR31130.1089945140/guido.python.org--
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