Andrew Straw wrote:
> Hi,
>
> I tracked down an issue that was giving me segfaults with a poor
> __getbuffer__ implementation and modified the compiler to catch this case.
Background first:
The situation is that this patch guards against returning erronous data
from a GetBuffer call. According to the PEP (3118), I think it is pretty
clear that data should either be set or an exception raised, so this
patch only helps detect when you create an invalid __getbuffer__
implementation.
(If I am wrong and the PEP says that the buf field can be set to NULL on
return then I'll of course apply the patch!)
I'd like input from others on this before making up my mind permanently,
but I'm -1 so far. The reason is that this belongs in a unit test that
you would write for your new buffer implementation, without adding
another redundtant if-test to all Cython buffer acquisitions that works
against correct getbuffer implementations.
With a unit test like that, you avoid runtime penalty everywhere, and
you also get to test strides, shape etc. for which you cannot insert
validation in a generic way in Cython (and so your patch check for
correct "buf" but not correct "strides" or "shape").
So what I would propose instead (though I'll never get time for it :-) )
is to have a reusable "buffer tester" library, i.e. use Cython to create
an application which checks that a given buffer can be acquired and
read, and then feed your custom buffer to it. We could thus create a
"standard PEP 3118 test" or similar.
For now this would involve manual __Pyx_GetBuffer calls like this:
cdef extern from *:
cdef int __Pyx_GetBuffer(obj, Py_buffer* info, int flags) except -1
... releasebuffer ..
... use __Pyx_GetBuffer and unit test the result for your buffer ...
(I have planned a function "cython.buffer.bufptr" though which would
make this easier; then you'd simply do
...
def testAcquisition(self):
cdef object[int] mybuf = ...
if cython.buffer.bufptr(mybuf) == NULL:
self.fail("__getbuffer__ didn't fill out the buf field")
)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev