Guido van Rossum <guido at python.org> writes: >> [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. That's exactly the sort of case that covers up bugs in C++. Our operator delete basically just ignores NULL values. When people write delete p; p = 0; It can cover up bugs where p is unintentionally getting deleted twice. It might still not be applicable here, though. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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