On Wed, Jul 8, 2009 at 18:28, Pauli Virtanen<[email protected]> wrote: > On 2009-07-08, Charles R Harris <[email protected]> wrote: >> In that case I don't see a problem offhand. That said, I haven't looked at >> the code yet. > > I'm a bit worried about the problem that cropped up in the ticket > with the complex ufuncs. As Luca noted in the ticket, > > obj3 = PyArray_Conjugate((PyAO *)obj1, NULL); > > needed to be replaced with > > Py_INCREF(obj1); > obj3 = PyArray_Conjugate((PyAO *)obj1, NULL); > Py_DECREF(obj1); > > to avoid overwriting obj1 when refcount of `obj1 == 1`. > > Now, having refcounts of 1 can be a common condition in arrays in > C code, and PyArray_Conjugate is a public function in Numpy's > C-API. So, as it stands now, this patch seems to potentially > break existing C-extension modules that use the Numpy/Numeric > API. This would need to be fixed. > > > Perhaps the INCREF/DECREF pair can be moved inside > PyArray_Conjugate.
It's entirely possible that this should be done regardless. > If I understand correctly similar issues can > only crop up in functions calling the *GenericUnary* etc. ufunc > functions directly. Are these functions part of the public API? > If not, there's a chance of fixing their callers inside Numpy. The public API is exactly the set of function pointers in PyArray_API and PyUFunc_API. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
