[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200722002115.GU14669@brightrain.aerifal.cx>
Date: Tue, 21 Jul 2020 20:21:16 -0400
From: Rich Felker <dalias@...c.org>
To: Ariadne Conill <ariadne@...eferenced.org>
Cc: musl@...ts.openwall.com
Subject: Re: perhaps we should add re[c]allocarray?
On Tue, Jul 21, 2020 at 05:21:03PM -0600, Ariadne Conill wrote:
> Hello,
>
> On Tuesday, July 21, 2020 2:40:53 PM MDT you wrote:
> > On Tue, Jul 21, 2020 at 08:58:04PM +0200, Florian Weimer wrote:
> > > * Rich Felker:
> > > > recallocarray presumably needs to zero the new part which means it
> > > > needs to know the old exact size, which means it depends on having
> > > > either knowledge of implementation internals or a working, exact
> > > > malloc_usable_size (AFAIK all legacy/existing ones except musl
> > > > mallocng are broken and return a value greater than the originally
> > > > allocated size).
> > >
> > > The caller has to pass the old member count to recallocarray, in an
> > > additional argument. I think this avoids this particular issue, and
> > > also makes it easy to achive interposition-safety.
> >
> > Ah, great, that makes it a non-issue then, and in that case I have no
> > significant objections to it.
>
> Okay great. I will work on reallocarray() first and then follow up with
> recallocarray().
Yes, reallocarray should be very straightforward. I think
recallocarray should probably involve a slight refactor of calloc.c to
make mal0_clear external so it can be reused; otherwise recallocarray
would be significantly worse than calloc/memcpy/free since it would
fault in all pages right away.
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.
