Re: [musl] [PATCH] implement recallocarray(3)

[Ariadne Conill <ariadne@dereferenced.org>]

Hello,

On Saturday, 1 August 2020 11:46:41 MDT Rich Felker wrote:
> 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?

Yes, EINVAL is mentioned in the man page.

    If ptr is not NULL and multiplying oldnmemb and size results in
    integer overflow recallocarray() returns NULL and sets errno to
    EINVAL.

They do not mention any rationale for returning EINVAL here, but they do clear 
any memory before reclaiming it on a shrink, so that may be related.  We could 
remove the check, but I added the check to be consistent with OpenBSD.

Ariadne