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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 7808 invoked from network); 22 Jul 2020 00:18:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Jul 2020 00:18:38 -0000 Received: (qmail 15782 invoked by uid 550); 22 Jul 2020 00:18:35 -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 29720 invoked from network); 21 Jul 2020 23:21:19 -0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced.org; s=default; t=1595373668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7ZqbUXCyk6vBTzzeuG726MZZCeHKGLtd94Y56zETR10=; b=adq03Zy4McclH/VDMdXr/ITVOwpHfR3XsMnQG1ZVMXpcMKeV1HVSrLWHLj7NbcwzHKKKUU MSbuZ3NqT1ScRJZPTM1iXUPRNWRiHmLOtp5hp9Jc3AkWv/6Bg72BWSaIMNI8jnEaHTPrcG nEq7VaNdu4zCTj/v6c5JbtGLdPuIYfg= From: Ariadne Conill To: Rich Felker Cc: musl@lists.openwall.com Date: Tue, 21 Jul 2020 17:21:03 -0600 Message-ID: <7497387.rXyXHT2FuX@localhost> In-Reply-To: <20200721204052.GR14669@brightrain.aerifal.cx> References: <3289935.7VNl89jVkd@localhost> <87pn8or8zn.fsf@mid.deneb.enyo.de> <20200721204052.GR14669@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [musl] perhaps we should add re[c]allocarray? 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(). Ariadne