Serhiy Storchaka added the comment:
When function sets an exception, it should return NULL. Otherwise the behavior
of the interpreter is undefined, it can crash in debug build or developing mode.
See for example
Zdeněk Pavlas added the comment:
Yes, found that *certain* IO operations re-raise the error, too. However, if
the Python runtime expects extension writers to keep tstate-curexc_type clear,
it should be documented in
http://docs.python.org/2/c-api/exceptions.html
There's not a single use
New submission from Zdeněk Pavlas:
documentation
There is a global indicator (per thread) of the last error that occurred. Most
functions do not clear this on success, but will set it to indicate the cause
of the error on failure. Most functions also return an error indicator, usually
NULL if
Ezio Melotti added the comment:
Can you provide an actual example to reproduce the error?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17544
___
Zdeněk Pavlas added the comment:
static PyObject*
foo(PyObject *, PyObject *arg)
{
void *buf;
Py_ssize_t size;
if (PyObject_AsReadBuffer(arg, buf, size))
size = -1;
return PyInt_FromLong(size);
}
import tst, re
re.search(a, a)
_sre.SRE_Match object at 0xb76d0950
Amaury Forgeot d'Arc added the comment:
The returned value and the global indicator are not independent. C functions
should not set an error while returning a valid value.
The same behavior will occur in random places -- for example, for x in
range(2): pass also triggers the issue, this is
