Wg: Re: [Python-checkins] cpython (3.4): Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer
== == == == == == Weitergeleitete Nachricht == == == == == == Absender : Stefan Krah<stefan@bytereef.org> Empfänger : "Victor Stinner"<victor.stinner@gmail.com> Datum : So, 01 Mrz 2015 18:58:43 +0000 Betreff : Re: [Python-Dev] [Python-checkins] cpython (3.4): Issue #23446: Use PyMem_New instead of PyMem_Malloc to avoid possible integer == == == == == == Weitergeleitete Nachricht == == == == == == 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
participants (1)
-
s.krah