Neil Schemenauer
> Okay. Perhaps I am missing something but would fixing it be as
> simple as adding another field to the tp_as_buffer struct?
>
> /* references returned by the buffer functins are valid while
> * the object remains alive */
> #define PyBuffer_FLAG_SAFE 1
>
> Then in stringobject.c (and elsewhere as appropriate):
>
> static PyBufferProcs buffer_as_buffer = {
> (getreadbufferproc)buffer_getreadbuf,
> (getwritebufferproc)buffer_getwritebuf,
> (getsegcountproc)buffer_getsegcount,
> (getcharbufferproc)buffer_getcharbuf,
> PyBuffer_FLAG_SAFE,
> };
>
> Then change bufferobject so that it can only be created from objects
> that set PyBuffer_FLAG_SAFE.
As the essence of the solution, I think that sounds good! I think that the
following should also be done:
* Update the docs for the buffer functions to indicate that these are *short
term* pointers, that are not guaranteed once *any* Python code is called.
* Add new public buffer functions with "LongTerm" in the name (and docs that
buffer is valid as long as the object). These check the flag as you
propose.
* Buffer object uses new LongTerm buffer functions.
It points out that the buffer object itself is less at fault than the
interface. I'm trying to short-circuit bugs in external extension modules
that use the buffer functions without realizing the subtle assumptions made.
Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4