Date: Tue, 21 Jul 2020 14:39:46 -0400 From: Rich Felker <dalias@...c.org> To: Ariadne Conill <ariadne@...eferenced.org> Cc: musl <musl@...ts.openwall.com> Subject: Re: perhaps we should add re[c]allocarray? On Tue, Jul 21, 2020 at 04:18:35AM -0600, Ariadne Conill wrote: > Hello, > > reallocarray and recallocarray are BSD extensions that solve similar issues as > strlcpy/strlcat, but with array reallocations instead of strings. > > reallocarray itself is already part of glibc since 2.28. > > Unfortunately, while working on new ifupdown implementation for Alpine, I > wanted to use recallocarray because it is very helpful in terms of pushing new > strings to a string array (you will always maintain a NULL-terminated array, > and you don't have to worry about it) -- but I discovered musl still does not > have it. > > Anyway, I think it would be useful to include both functions in musl 1.2.1. > If everyone agrees, I'll make a patch. reallocarray is a straightforward wrapper around realloc that can be implemented portably to work with arbitrary underlying malloc and is fairly non-controversial. I think it was already loosely agreed at some point that we would eventually support this. 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). Implementing it interferes with safety of overriding/interposing malloc, and therefore I'm fairly strongly against it unless there's a widepread consensus between implementors that it should exist. Is there a strong reason you want recallocarray rather than just reallocarray? 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.