[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
