[Patches] [ python-Patches-552438 ] PyBufferObject fixes

[noreply@sourceforge.net]

Patches item #552438, was opened at 2002-05-05 06:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Scott Gilbert (xscott)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyBufferObject fixes

Initial Comment:
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.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-12-05 17:58

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-24 22:36

Message:
Logged In: YES 
user_id=31435

Since Scott is on to something else, marked this Postponed 
and unassigned it.

----------------------------------------------------------------------

Comment By: Scott Gilbert (xscott)
Date: 2002-07-23 10:03

Message:
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. 


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-07-18 21:41

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-07 20:51

Message:
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.

----------------------------------------------------------------------

Comment By: Scott Gilbert (xscott)
Date: 2002-05-07 14:55

Message:
Logged In: YES 
user_id=38318

Apparently assigning a patch is poor form.  My bad.

----------------------------------------------------------------------

Comment By: Scott Gilbert (xscott)
Date: 2002-05-05 06:27

Message:
Logged In: YES 
user_id=38318

Can I assign this to you or does it take admin privs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470