Author ncoghlan
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.22:01:04
SpamBayes Score 6.07958e-13
Marked as misclassified No
Message-id <1297634465.58.0.479885788421.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
I'm still not comfortable with a convention that relies on *clients* of the PEP 3118 API not mucking with the internals of the Py_buffer struct.

I'm *much* happier with the rule based on malloc/free semantics where the *pointer* passed to PyObject_GetBuffer must match a single later call to PyObject_ReleaseBuffer. This is also a convention that should be quite familiar to any C/C++ developers using the API directly.

Note my comment earlier, pointing out that under those rules, dup_buffer actually does the right thing given the way it is used in the current implementation, but there's one current bug (issue 9990) where the wrong address is passed to the release buffer call - get_buffer is called with a stack address, the contents are copied to a heap address, then the heap address is used in the release_buffer call.
History
Date User Action Args
2011-02-13 22:01:05ncoghlansetrecipients: + ncoghlan, loewis, teoliphant, mark.dickinson, rupole, kermode, pitrou, pv
2011-02-13 22:01:05ncoghlansetmessageid: <1297634465.58.0.479885788421.issue10181@psf.upfronthosting.co.za>
2011-02-13 22:01:05ncoghlanlinkissue10181 messages
2011-02-13 22:01:04ncoghlancreate