Greg Ewing wrote: > Walter Dörwald wrote: > >> The "checking for NULL" scenario looks somewhat like this: >> >> And the "clearing the reference" scenario should look ike this: > > But only if the reference is a local to the function,
True Py_CLEAR(foo->bar->baz) probably won't be optimized. > and it's used in a disciplined enough way, and the > compiler is smart enough. None of those things are > guaranteed true for all uses of Py_DECREF/Py_XDECREF. I tried simply replacing all Py_DECREF()/Py_XDECREF() calls with Py_CLEAR with the result that nothing works any more. ;) Modules/posixmodule.c uses Py_DECREF(Py_None) which can't work with Py_CLEAR, because Py_None is not an lvalue. Python/import.c::PyImport_AddModule() returns m after doing a Py_DECREF, so this would have to continue to use Py_DECREF() (or do a dance with a second local variable). Python/compile.c::makecode() must use Py_DECREF, because the variable is still checked afterwards. Python/symtable.c::symtable_new_tmpname() and Python/compile.c::compiler_listcomp() (and probable many others) use the same var name as the Py_CLEAR macro which doesn't work. Objects/dictobject.c::insertdict() does a Py_DECREF(dummy), but that probably shouldn't clear dummy. And then I gave up. If we would do this, IMHO it would only make sense to do it the other way round: Replace Py_(X)DECREF with Py_CLEAR in selected spots. But that's not much different from what has happened up to now. Servus, Walter _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
