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 8173 invoked from network); 22 Jul 2020 00:21:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Jul 2020 00:21:30 -0000 Received: (qmail 17928 invoked by uid 550); 22 Jul 2020 00:21:28 -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 17910 invoked from network); 22 Jul 2020 00:21:28 -0000 Date: Tue, 21 Jul 2020 20:21:16 -0400 From: Rich Felker To: Ariadne Conill Cc: musl@lists.openwall.com Message-ID: <20200722002115.GU14669@brightrain.aerifal.cx> References: <3289935.7VNl89jVkd@localhost> <87pn8or8zn.fsf@mid.deneb.enyo.de> <20200721204052.GR14669@brightrain.aerifal.cx> <7497387.rXyXHT2FuX@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7497387.rXyXHT2FuX@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 05:21:03PM -0600, Ariadne Conill wrote: > Hello, > > On Tuesday, July 21, 2020 2:40:53 PM MDT you wrote: > > On Tue, Jul 21, 2020 at 08:58:04PM +0200, Florian Weimer wrote: > > > * Rich Felker: > > > > 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). > > > > > > The caller has to pass the old member count to recallocarray, in an > > > additional argument. I think this avoids this particular issue, and > > > also makes it easy to achive interposition-safety. > > > > Ah, great, that makes it a non-issue then, and in that case I have no > > significant objections to it. > > Okay great. I will work on reallocarray() first and then follow up with > recallocarray(). Yes, reallocarray should be very straightforward. I think recallocarray should probably involve a slight refactor of calloc.c to make mal0_clear external so it can be reused; otherwise recallocarray would be significantly worse than calloc/memcpy/free since it would fault in all pages right away. Rich