sip - returning a MemoryView in %ConvertFromTypeCode

[Phil Thompson]

On 27/12/2021 11:31, Phil Thompson wrote:
> On 26/12/2021 21:47, Scott Talbert 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.

Phil