|
Message-ID: <12374637.q0HFhEdf7Z@localhost> Date: Tue, 21 Jul 2020 18:24:14 -0600 From: Ariadne Conill <ariadne@...eferenced.org> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: perhaps we should add re[c]allocarray? Hello, On Tuesday, July 21, 2020 6:21:16 PM MDT Rich Felker wrote: > 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. Yeah, I was going to alias mal0_clear to __malloc_mal0_clear or similar as part of recallocarray work. Ariadne
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.