|
Message-ID: <20200801174640.GX6949@brightrain.aerifal.cx> Date: Sat, 1 Aug 2020 13:46:41 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] implement recallocarray(3) On Sat, Aug 01, 2020 at 10:23:35AM -0600, Ariadne Conill wrote: > On Saturday, 1 August 2020 09:52:28 MDT Markus Wichmann wrote: > > On Sat, Aug 01, 2020 at 08:46:58AM -0600, Ariadne Conill wrote: > > > +void *recallocarray(void *ptr, size_t om, size_t m, size_t n) > > > +{ > > > + void *newptr; > > > + size_t old_size, new_size; > > > + > > > + if (n && m > -1 / n) { > > > + errno = ENOMEM; > > > + return 0; > > > + } > > > + new_size = m * n; > > > + > > > + if (n && om > -1 / n) { > > > + errno = EINVAL; > > > + return 0; > > > + } > > > + old_size = om * n; > > > + > > > + if (new_size <= old_size) { > > > + memset((char *) ptr + new_size, 0, old_size - new_size); > > > + } > > > + > > > + newptr = reallocarray(ptr, m, n); > > > + if (new_size > old_size) { > > > + memset((char *) ptr + old_size, 0, new_size - old_size); > > > + } > > > + > > > + return newptr; > > > +} > > > > Is there a reason for the call to reallocarray? The multiplication m * n > > has already been tested for overflow and executed at that point. Might > > as well just call realloc() there, right? > > Good catch. I decided to use reallocarray() simply for clarity, but I can > change it to a realloc() call. I'm also confused why the old size has to be checked at all. There's inherently a contract that the old size be correct for the existing allocation; if it's not, the wrong number of members will be zeroed. Checking whether om*n overflows does not change this and does not catch the more general case where om is wrong. Is the EINVAL behavior from OpenBSD, and if so, do they have a rationale for it? Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.