RetroSearch Browse

Thu Feb 5 19:19:01 CET 2009 · https://mail.python.org/pipermail/python-dev/2009-February/085890.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-February/085890.html below:

[Python-Dev] Why a STACKADJ(-1) in UNARY_NOT on ceval.c?