sip - returning a MemoryView in %ConvertFromTypeCode

[Phil Thompson]

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.

Phil