Re: [musl] perhaps we should add re[c]allocarray?

[Leah Neukirchen <leah@vuxu.org>]

Rich Felker <dalias@libc.org> writes:

> 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.

No, it's an argument:
void *recallocarray(void *ptr, size_t oldnmemb, size_t newnmemb, size_t size)

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/