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 2462 invoked from network); 3 Aug 2020 00:45:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2020 00:45:40 -0000 Received: (qmail 1286 invoked by uid 550); 3 Aug 2020 00:45:37 -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 1216 invoked from network); 3 Aug 2020 00:45:34 -0000 Date: Sun, 2 Aug 2020 20:45:19 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200803004519.GZ6949@brightrain.aerifal.cx> References: <20200802225426.32002-1-ariadne@dereferenced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200802225426.32002-1-ariadne@dereferenced.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v4] implement recallocarray(3) On Sun, Aug 02, 2020 at 04:54:26PM -0600, Ariadne Conill wrote: > This OpenBSD extension is similar to reallocarray(3), but > zero-initializes the new memory area. > > This extension is placed in _BSD_SOURCE, like > reallocarray(3). > > Changes from v3: > - use calloc() instead of realloc() and always copy > - explicitly zero old memory block > - restore overflow checking for old size > > Changes from v2: > - drop overflow checking for old size > > Changes from v1: > - use realloc() instead of reallocarray() Can we finish discussion of questions raised before making new versions with changes that haven't even been agreed upon? I asked about EINVAL so we could determine if it's expected and if it's reasonable to copy; that's not a demand to remove it. And the new memset before free is a complete no-op. If there's a contract to behave like explicit_bzero on the old memory, we may want to honor that if we implement recallocarray, but that likely makes it entirely unsuitable to the purpose you want it for and will bring back the atrociously bad apk performance you previously saw with mallocng if you use it there, since each increment of array size will incur a whole memcpy of the existing array (quadratic time) rather than copies only occuring a logarithmic number of times (yielding O(n log n) overall) as would happen with realloc. Overall I'm getting kinda skeptical of this function. Implementing it without the hardness guarantees of the OpenBSD version seems like a bad idea, but with those guarantees it just seems to be a bad interface. Rich