[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. 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.
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