sip - returning a MemoryView in %ConvertFromTypeCode

[Scott Talbert]

On Mon, 27 Dec 2021, Phil Thompson wrote:

>>> Hi,
>>> 
>>> I'm trying to fix a bug in wxPython where a MemoryView is returned in
>>> a %ConvertFromTypeCode.
>>> 
>>> The code is this:
>>> PyObject* i_wxPyMakeBuffer(void* ptr, Py_ssize_t len, bool readOnly=false) 
>>> {
>>>     wxPyThreadBlocker blocker;
>>>     if (ptr && len) {
>>>         Py_buffer view;
>>>         int flags = PyBUF_FORMAT|PyBUF_ND;
>>>         if (!readOnly)
>>>             flags |= PyBUF_WRITABLE;
>>>         PyBuffer_FillInfo(&view, NULL, ptr, len, readOnly ? 1:0, flags);
>>>         return PyMemoryView_FromBuffer(&view);
>>>     } else {
>>>         Py_INCREF(Py_None); return Py_None;
>>>     }
>>> 
>>> %ConvertFromTypeCode
>>>     return wxPyMakeBuffer(sipCpp->GetData(), sipCpp->GetDataLen());
>>> %End
>>> 
>>> This "works" but the problem is that after %ConvertFromTypeCode runs,
>>> the C++ object goes away, and since the MemoryView still references
>>> data from the C++ object, this leads to accessing memory that has been
>>> freed.  Is there a recommended way to handle such a situation with
>>> sip?  Ie, keep the C++ object around after a %ConvertFromTypeCode?  Of
>>> course, I could copy the all the data in %ConvertFromTypeCode, but
>>> that's the thing we're trying to avoid by using the MemoryView.
>> 
>> I don't see how SIP generated code can help as it's really a
>> limitation of MemoryView. It needs to support the concept of the
>> MemoryView owning the underlying data and being able to provide a
>> destructor similar to a Capsule.
>
> An alternative might be sip.array...
>
> https://www.riverbankcomputing.com/static/Docs/sip/abi_12.html#c.sipConvertToArray
>
> However the destructor is hard-coded to be free(), so you might need it 
> enhanced to allow another destructor to be able to be specified.

Thanks for the info.  I had been looking at sip.array, too.

Scott