On Mon, Feb 16, 2015 at 10:14:59PM +0100, Victor Stinner wrote:
> 2015-02-16 17:34 GMT+01:00 Stefan Krah <stefan@bytereef.org>:
> >
> > On Mon, Feb 16, 2015 at 11:35:52AM +0000, serhiy.storchaka wrote:
> >> diff --git a/Modules/_testbuffer.c b/Modules/_testbuffer.c
> >> --- a/Modules/_testbuffer.c
> >> +++ b/Modules/_testbuffer.c
> >> @@ -850,7 +850,7 @@
> >> Py_ssize_t *dest;
> >> Py_ssize_t x, i;
> >>
> >> - dest = PyMem_Malloc(len * (sizeof *dest));
> >> + dest = PyMem_New(Py_ssize_t, len);
> >> if (dest == NULL) {
> >> PyErr_NoMemory();
> >> return NULL;
> >
> > This, too, was already protected by len == ndim <= 64.
>
> I don't understand why you don't want to use PyMem_New() even if it
> cannot overflow. PyMem_New() is more readable no?

It's readable, but I don't see a reason to change code that already has an
overflow analysis, especially in 3.4.

As I wrote in http://bugs.python.org/issue23446#msg235770 , people need to
see that one *can* make certain assumptions about PEP-3118 buffers (otherwise
one would go insane with overflow checks when doing arithmetic on the buffers.


So, in a sense, this commit removes information for the reader. I would
prefer an "assert(len <= 64)" for documentation purposes while keeping the
multiplication.



Stefan Krah