Stefan Krah added the comment:
On second thought, it's impossible to crash a memoryview generated
by PyMemoryView_FromBuffer(info) even when info->shape etc. point
to stack addresses.
The reason is this: All new memoryviews are created through the mbuf_add*
API. In the first call to mbuf_add_view(mbuf, NULL) the stack addresses
are still valid, and the private shape, strides and suboffsets of the
first memoryview that is registered with the managed buffer are
initialized correctly.
Now PyMemoryView_FromBuffer() returns and the managed buffer itself
contains invalid stack addresses. But these are never used again!
Chained memoryviews are generated from existing memoryviews, and
they are registered with the managed buffer by calling
mbuf_add_view(mbuf, existing_view->view).
mbuf_add_incomplete_view(mbuf, NULL, ndim) does not access shape, strides
and suboffsets.
If info->format points to a stack address, it would crash both the
old and new implementations. I'd regard such a use of info->format
silly.
I've never considered this use of PyMemoryView_FromBuffer(info) legitimate,
but it works in the new implementation. If we officially endorse this
pattern, then info->format should probably also be copied.
So the topic is reduced to:
1) Previous: If non-NULL, steal the view.obj reference with automatic
decrement in PyBuffer_Release().
New: If non-NULL, treat view.obj as a borrowed reference.
2) Copy info->format?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15821>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
