While re-writing the PyNumber_InPlace*() functions in augmented assignment
to something Guido and I agree on should be the Right Way, I found something
that *might* be a bug. But I'm not sure.
The PyNumber_*() methods for binary operations (found in abstract.c) have
the following construct:
if (v->ob_type->tp_as_number != NULL) {
PyObject *x = NULL;
PyObject * (*f)(PyObject *, PyObject *);
if (PyNumber_Coerce(&v, &w) != 0)
return NULL;
if ((f = v->ob_type->tp_as_number->nb_xor) != NULL)
x = (*f)(v, w);
Py_DECREF(v);
Py_DECREF(w);
if (f != NULL)
return x;
}
(This is after a check if either argument is an instance object, so both are
C objects here.) Now, I'm not sure how coercion is supposed to work, but I
see one problem here: 'v' can be changed by PyNumber_Coerce(), and the new
object's tp_as_number pointer could be NULL. I bet it's pretty unlikely that
(numeric) coercion of a numeric object and an unspecified object turns up a
non-numeric object, but I don't see anything guaranteeing it won't, either.
Is this a non-issue, or should I bother with adding the extra check in the
current binary operations (and the new inplace ones) ?
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
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