It's to make up for the lack of SET_TOP in that path. On Thu, Feb 5, 2009 at 10:19 AM, Cesare Di Mauro <cesare.dima...@a-tono.com> wrote: > Looking at the UNARY_NOT case in ceval.c: > > case UNARY_NOT: > v = TOP(); > err = PyObject_IsTrue(v); > Py_DECREF(v); > if (err == 0) { > Py_INCREF(Py_True); > SET_TOP(Py_True); > continue; > } > else if (err > 0) { > Py_INCREF(Py_False); > SET_TOP(Py_False); > err = 0; > continue; > } > STACKADJ(-1); > break; > > > I don't understand why there's a STACKADJ(-1) at its end. Looking at the > code, we know that if the CPU arrives to the STACKADJ, it's because of an > error condition in the PyObject_IsTrue that sets err to a < 0 value, so > exiting the big switch statement, an error will be raised. > > So the question is, why there's the need to skip the top stack PyObject? > It's a different behaviour comparing it to the all other unary operators. > For example: > > case UNARY_NEGATIVE: > v = TOP(); > x = PyNumber_Negative(v); > Py_DECREF(v); > SET_TOP(x); > if (x != NULL) continue; > break; > > There's no STACKADJ instruction on errors. > > Can someone explain it? > > Thanks a lot > > Cesare > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org >
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com