From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31760 invoked from network); 21 Jul 2020 18:40:01 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Jul 2020 18:40:01 -0000 Received: (qmail 23562 invoked by uid 550); 21 Jul 2020 18:39:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22520 invoked from network); 21 Jul 2020 18:39:58 -0000 Date: Tue, 21 Jul 2020 14:39:46 -0400 From: Rich Felker To: Ariadne Conill Cc: musl Message-ID: <20200721183945.GQ14669@brightrain.aerifal.cx> References: <3289935.7VNl89jVkd@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3289935.7VNl89jVkd@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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