[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
