From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C43041F5AE for ; Thu, 23 Jul 2020 10:23:18 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BD22C3857C5F; Thu, 23 Jul 2020 10:23:17 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 41CE03857C52 for ; Thu, 23 Jul 2020 10:23:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 41CE03857C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mliska@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 43F92ACDF; Thu, 23 Jul 2020 10:23:23 +0000 (UTC) Subject: Re: [PATCH] Use size_t for mallinfo fields. From: =?UTF-8?Q?Martin_Li=c5=a1ka?= To: Florian Weimer References: <87tuyja59i.fsf@igel.home> <87v9izxwo7.fsf@oldenburg2.str.redhat.com> <87lfjvxv58.fsf@oldenburg2.str.redhat.com> <093814cf-0b7d-1011-08e7-4d5c3e56b423@suse.cz> Message-ID: Date: Thu, 23 Jul 2020 12:23:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <093814cf-0b7d-1011-08e7-4d5c3e56b423@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andreas Schwab , libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" PING^1 On 7/8/20 9:24 AM, Martin Liška wrote: > On 7/7/20 4:22 PM, Florian Weimer wrote: >> * Martin Liška: >> >>> On 7/7/20 3:49 PM, Florian Weimer wrote: >>>> * Martin Liška: >>>> >>>>> On 7/7/20 2:17 PM, Andreas Schwab wrote: >>>>>> On Jul 07 2020, Martin Liška wrote: >>>>>> >>>>>>> The current int type can easily overflow for allocation of more >>>>>>> than 4GB. >>>>>>> >>>>>>> The following patch changes that to size_t. I guess I need to adjust >>>>>>> the API version of the function, right? >>>>>> >>>>>> Not only that, it breaks the ABI of mallinfo. >>>>> >>>>> Sure, so what options do I have? I'm new to glibc so a hint would be >>>>> appreciated. >>>> >>>> We need to add a new function.  Symbol versioning does not work because >>>> mallinfo is interposed by alternative mallocs (tcmalloc, Address >>>> Sanitizer, etc.).  Without the new function name, the interposer does >>>> not know which ABI the application expects, so it's going to be quite >>>> messy. >> >>> All right, am I closer with the suggested patch? >> >> If what I wrote above is right (we'd first gather consensus around >> that), we should probably add struct mallinfo2 and mallinfo2, deprecate >> the original mallinfo function, and eventually remove them from the >> public API (turning the original mallinfo into a compatibility symbol). > > All right, I'm sending patch for that. > >> >> I suppose it would make sense to raise this issue with the tcmalloc, tbb >> and Address Sanitizer people, to see if they would be willing to >> implement mallinfo2 on their end. > > Once we're done I can file issues to all these to inform them. > > Thoughts? > Martin > >> >> The end result, having mallinfo2 and not mallinfo, is a bit ugly, but >> it's an improvement over the current state.  I do not see a need to get >> creative with symbol redirects or symbol versions. >> >> Thanks, >> Florian >> >