This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: PyBufferObject fixes
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, loewis, tim.peters, xscott
Priority: normal Keywords: patch

Created on 2002-05-05 04:26 by xscott, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
bufferfix.diff xscott, 2002-05-05 04:26
Messages (8)
msg39873 - (view) Author: Scott Gilbert (xscott) Date: 2002-05-05 04:26
This patch fixes these problems:

  1) Dangling pointer problem
  2) buffer allocated by PyBuffer_New not aligned

The PyBufferObject acts differently depending on 
whether it allocated the memory or if it's borrowing 
the memory from a PyBufferProcs supporting object.

In the case of allocating it's own memory, I made a 
slight addition that adds some padding so that the ptr 
is on a sizeof(double) boundary.

In the case of borrowing another objects PyBufferProcs 
memory, PyBufferObject no longer caches the pointer.  
This might slow things down (probably not by much), 
but it keeps PyBufferObject from working with a stale 
pointer.


Normally I wouldn't do this, but since this patch 
touches pretty much every function anyway, I fixed 
many deviations from the Python coding style.

msg39874 - (view) Author: Scott Gilbert (xscott) Date: 2002-05-05 04:27
Logged In: YES 
user_id=38318

Can I assign this to you or does it take admin privs?
msg39875 - (view) Author: Scott Gilbert (xscott) Date: 2002-05-07 12:55
Logged In: YES 
user_id=38318

Apparently assigning a patch is poor form.  My bad.
msg39876 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-05-07 18:51
Logged In: YES 
user_id=31435

Na, assigning a bug is fine by me -- it helps to have 
*someone* feel guilty <wink>.  Assigning it doesn't mean it 
goes to the top of the assignee's heap, though.  I can't 
make time to look at it this week, so it's just as well 
that it got unassigned.
msg39877 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-07-18 19:41
Logged In: YES 
user_id=6380

Note, the patch is out of date since somebody fixed some
nits with slicing, so I'm marking this as Out Of Date.

You might as well upload the new version of the file. :-)

Why do you think you need to fix the allocation? Since
allocation is done via malloc(), and malloc() guarantees
allocation for a double ("for all types"), shouldn't that be
enough??? (If it's obmalloc that you're worried about, it's
easy to force this to use the real malloc() and free().)

I hope Tim will make some time to review this (the "not this
week" comment is several months old now). Superficially it
looks like a big improvement.
msg39878 - (view) Author: Scott Gilbert (xscott) Date: 2002-07-23 08:03
Logged In: YES 
user_id=38318

On top of the current patch being out of data, in private email, 
Guido indicated that Tim thinks the code needs more 
refactoring to simplify it.

I'd like to hold off on resubmitting a current patch to see how 
the bytes object fairs (PEP 296).  If the bytes object makes it 
into the Python core, then probably the best way to simplify 
and fix the implementation of the buffer object is to reduce it 
nothing but a "Buffer Inspector" for other objects.  (Tearing out 
the b_ptr field and a lot of if statements at least.)  The bytes 
object could be used to implement the following calls:

    PyBuffer_FromMemory(...)
    PyBuffer_FromReadWriteMemory(...)
    PyBuffer_New(...)

In these cases, the bytes object would hold the actual 
memory, and the buffer object would just be inspecting the 
bytes object.  I'd still stick to the strategy of having the buffer 
object re-request the pointer before every use (since typically 
the pointer is only valid while the GIL is held).  I haven't 
figured out how to handle the case when the size specified for 
the buffer object gets out of whack when the inspected object 
resizes.  Raise an exception?

Even with these changes, there would still be some problems 
in here.  For instance, the hash value is easy to invalidate. 
msg39879 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-07-24 20:36
Logged In: YES 
user_id=31435

Since Scott is on to something else, marked this Postponed 
and unassigned it.
msg39880 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-12-05 16:58
Logged In: YES 
user_id=21627

It appears that whatever the final outcome is, it will have little 
in common with the current patch.

So I'm closing it as rejected now; Scott, if you ever see the 
need to provide an updated version, feel free to either reopen 
it, or submit a new patch.
History
Date User Action Args
2022-04-10 16:05:17adminsetgithub: 36555
2002-05-05 04:26:05xscottcreate