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,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 23557 invoked from network); 21 Jul 2020 17:27:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Jul 2020 17:27:21 -0000 Received: (qmail 17887 invoked by uid 550); 21 Jul 2020 17:27:19 -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 17869 invoked from network); 21 Jul 2020 17:27:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1595352427; bh=NIwPVYBoKGnTGen4WPiRgIMzyjIzVxr2Sf9CUnqxnKQ=; h=Date:From:To:Subject:From; b=MLc/nZ7VwHIOhF2XE4UjzdUCr5ELHyfu/E4TC0AjaXNQKMNHR9rcaUl6GXQjXU2kV b0k70i79NYz6QesOL5+B7LplKF4Q1p0gWGKgq31snuXpq891jIYOJ/1fb5xx7K4FLz CMWdC5cBsbtTsgZ+/AGb+gMgfk/4uk1fDVhMbwByGhbCQOwQQvDXQ1vMdvyUVkIpPl mcbq0csKdqGOrcLDUZ9Emmx0dbo7caHvkrrA5stUtPw4iwEKiL1uqOi+o0kyxNvab6 JrQPAO0MHqNsun25hD8/46rC3vFarJ0ahgizJZcm+AcC3CNzz04P/MBusznv+cPClO aSmUdLOCvZyXA== Date: Tue, 21 Jul 2020 19:27:02 +0200 From: Hadrien Lacour To: musl@lists.openwall.com Message-ID: <20200721172702.rk6moi2a2dc25c7v@gentoo-zen2700x> References: <3289935.7VNl89jVkd@localhost> <20200721165657.GA2160@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200721165657.GA2160@voyager> Subject: Re: [musl] perhaps we should add re[c]allocarray? On Tue, Jul 21, 2020 at 06:56:57PM +0200, Markus Wichmann wrote: > 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. > > > > 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 I'm pretty sure the point of reallocarray is that it checks for overflow during the multiplication of the arguments.