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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 20159 invoked from network); 21 Jul 2020 16:57:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Jul 2020 16:57:12 -0000 Received: (qmail 28094 invoked by uid 550); 21 Jul 2020 16:57:10 -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 28073 invoked from network); 21 Jul 2020 16:57:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595350618; bh=daKXCxlTUMpPg233WUOkM6iKTJJWa9YHUueD70m/BrU=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=NrNP/7jYIIqrsUyZwtDhO/dbPWrmf4Euu9psHiyQO9679+4ZttSE5LqVYQWYRE6WT wZJ20s/CEt6MFwIf0RikjevPTLMSL3kmyOVa4+H9BK9hryWakiVze2pOSEtvpSjrpY 0lIj2iWuMRwtJd5TgL375SkM1G/A8fG12SF4LcLE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Tue, 21 Jul 2020 18:56:57 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200721165657.GA2160@voyager> 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.9.4 (2018-02-28) X-Provags-ID: V03:K1:J4biOwoYfJ/JCkQkEApF6j7dqr0s+AzwyIz05Tlcte1pIMVyP9/ b67QEdgiB3RaUHznsQuoU4niqvHs5LTbKuhyBMHTlpjg08zmm4q7ijBPpJmxVNW4QYwEfee myw6CpvgDJGF0UH1CAfW1fCsIXWLRC1EtbriPR4tdO8fXoTwFR1p4MgzQjFrVgrXEDl41xr UesbYX5OS3iqV+9abxEfA== X-UI-Out-Filterresults: notjunk:1;V03:K0:mHOjl5EFToU=:XO/IO3BGWdAJJB3LW+HVol ch4kj8hB95t6u8GImvgs57LRKOwdZCSNvNX2yMkEwW82j0dPg/U7+7n3WQ5VV9BVK6s0Ojg2h F4cEfe0yo9Fa5psp7LmeOr8DCHPXAkIYjKLvQvzgiLQ8mDSH1VyOwfMLiq7q33r/wP29StndL TyFKj9keNsSXQyJwxT4cSbbYNVf8ohb+vxjknGqR3jKuJJUbcPqLEvolSa9rI3XyYIi7zcuoa 3Qsk+wgIJPtMQQQ+3O4pRkwVojN9c/K3gevF8ovuUaqd12zY0AStygj0iswQY+mPdAg6rOY8U Ifz0DRHiueoxDcVaK8i3/m69zUs+viNgLnsEOw5baujd/93LLmxLUylQ9i6Dm86CDLTdKO2f5 e3JYaJ35k69L0emYfuAHC7rY0p/uR52U8fYbeR+iaFjEYu/xKzKXd1x1+y374cTLBtlwEpMsu r+m3kyTSpwBwYLtzExUDBVb41PI+I96/AEE4W2Xx8NpQ+3XfQAO/yT/LhrssplnMmcWlzLiNi LDo+uccJm77WCO7ODxjzpQibp/rnaHI5Io8fADu6So0J43Od2UkVR8DYuHVuj4zArMZMlpeES P+q5aSXXkmGu35U0V0Wogfbgxwr8vt0HIwQjlNOJoUDSudk+FVMYGIp6EB7XTG8EtNLrH1v9q z4jotjjUIVvHZjlm/40Q8JuM3exa203It/RTB+gDomFaTgUpBF/AIUMLhQpGsI8qYKbuyP/QH Fb/SW1Kyue4yN3vS+egiarnRk5M6WT7qQTQ/9vUAmxfJk4t0zu1F/0ima5+vly1nyKRbVhdno eFhuJlyqFCkrtDhShCGCqv3BYDMs2kypG6p+stqaAQxZ9w9a4ZVJx/haV8SDgmVU6QLP3CPy7 XFjiQQmAOav+v40JMyy3gOoKwTlxuQ+/V8zqi9SbC3wgTQDt36cXupSwgTSTAg8vpPon+/j+h 5tnPpQZ9VXryYGd0il6xk0s0OWxpTdReaePD+pcfs0iHKKLcuj2OVeukt2tPQumT80AFd/Exw itQ4eNg1DWuuxYcQzwyfOSrHmAPrn2Qlw4/5k7VpXb+Kl3V6LPbAXNm7W7d4SnpZXNu1fDg+/ w7UJ4OHOZjg1qP/KJfvy/2ftgD5aBNotL+747gMpz8sI+bB68Jjq/AVckpHMWKOjPM+Rl4JE/ ki1wz0+feCG67R8w2LytsH3wuQ6DHbfz31Ilwmj0T0Kz6X1l4aIPVrPmgAz57CUMN4SpN9SPm kQPqgxqtS3DRvc9gW Content-Transfer-Encoding: quoted-printable 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 iss= ues 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 pushi= ng new > strings to a string array (you will always maintain a NULL-terminated ar= ray, > and you don't have to worry about it) -- but I discovered musl still doe= s 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. > > Ariadne > > Seems mostly useless to me. reallocarray() is equivalent to realloc(), multiplying the last two arguments. And recallocarray() does seem useful, but moreso as a subroutine. I see little reason to put this into a standard library. On a formal point of view, neither of these has been standardized. I can find an Oracle man page for reallocarray(), but not recallocarray(). Both are OpenBSD extensions. For glibc, I can find reallocarray() (which mostly wraps realloc()), but no recallocarray() (I checked in the most recent released version, which is 2.31 as of right now). It appears, reallocarray() enjoys more widespread adoption than recallocarray(). Both can, however, be easily found by a compile/link test. As stated above, however, the necessary functionality can easily be written in whatever application needs it, so I don't see the point. I've done that before; it is two lines if you manage your variables well. JM2C, Markus