Making a C extension compatible with 2.2

[Martin v. Loewis]

Hamish Lawson <hbl at st-andrews.ac.uk> writes:

> Aha! It so happens it's also ingmod that my problem relates to! :-)  I
> recently notified Holger Meyer about it and he said he would try to
> address it soon, but I thought I would see what I could do myself in the
> meantime (though I'm far from expert on writing C extensions for
> Python).

That module appears to lack checks for exceptions in a number of
places. For example:

#define	STR(obj)			(PyString_AsString(PyObject_Str(obj)))

This can easily fail: If PyObject_Str raises an exception, it will
return NULL. That would crash the interpreter, though.

Also, when allocating things, it often does not check for
errors. E.g. in sqlda_description:

	list = PyList_New(0);
	for (i = 0, v = sqlda->sqlvar; i < sqlda->sqld; ++i, ++v) {
...
		tuple = PyTuple_New(7);

The code should check both list and tuple for NULL.

			prec = PyInt_FromLong((long)IISQL_PRCSN(v->sqllen));
			scale = PyInt_FromLong((long)IISQL_SCALE(v->sqllen));

Here, prec and scale may be NULL.

In turn, callers of sqlda_description don't check for exceptions:

	self->descr = sqlda_description(self->out);

or

		if (self->out) {
			if (!self->descr) {
				self->descr = sqlda_description(self->out);
			}
			if (self->descr) {
				Py_INCREF(self->descr);
				return(self->descr);
			}
		}
		Py_INCREF(Py_None);
		return(Py_None);

If sqlda_description returns NULL to report an exception, this
fragment will return None, instead of reporting the exception further
out.

It will be hard to find all these problems, but I think Just was right
that the likely cause is an unreported exception, which will show up
the next time somebody calls PyErr_Occurred.

Regards,
Martin