From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iNjVGSABsl/2VAAAWB0awg (envelope-from ) for ; Sun, 15 Nov 2020 23:33:36 -0500 Received: by simark.ca (Postfix, from userid 112) id 64C451F08B; Sun, 15 Nov 2020 23:33:36 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=unavailable 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 (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 107831E58D for ; Sun, 15 Nov 2020 23:33:36 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C7656389200A; Mon, 16 Nov 2020 04:33:35 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id A23043857C69 for ; Mon, 16 Nov 2020 04:33:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A23043857C69 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7F5E91161AB; Sun, 15 Nov 2020 23:33:33 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G+B0Wde7G0yS; Sun, 15 Nov 2020 23:33:33 -0500 (EST) Received: from float.home (localhost.localdomain [127.0.0.1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 23918116144; Sun, 15 Nov 2020 23:33:33 -0500 (EST) Received: by float.home (Postfix, from userid 1000) id 3C4D2A1872; Mon, 16 Nov 2020 07:55:01 +0400 (+04) Date: Mon, 16 Nov 2020 07:55:01 +0400 From: Joel Brobecker To: Simon Marchi Subject: Re: [RFA 1/6] change gmp_string_asprintf to return an std::string Message-ID: <20201116035501.GB609903@adacore.com> References: <1604817017-25807-1-git-send-email-brobecker@adacore.com> <1605430184-81335-1-git-send-email-brobecker@adacore.com> <1605430184-81335-2-git-send-email-brobecker@adacore.com> <3e16e18e-e5bc-7d6a-1404-19c7d22cda6e@simark.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e16e18e-e5bc-7d6a-1404-19c7d22cda6e@simark.ca> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Simon, > On 2020-11-15 3:49 a.m., Joel Brobecker wrote: > > This was suggested by Simon during a code review of this package upstream. > > The upside is that this makes the function's API more natural and C++. > > The downside is an extra malloc, which might be the reason why we went > > for using a unique_xmalloc_ptr in the first place. Since this function > > is not expected to be called frequently, the API improvement might be > > worth the performance impact. > > In fact, I was thinking of doing the exact same thing as the > string_print function. By calling vsnprintf with a NULL buffer, you can > get how many bytes would be required to hold the result. You can then > allocate the required buffer and call vsprintf with it. > > So, there's no extra allocation, although it requires formatting twice. > But if it's good enough for string_printf (which is heavily used), it's > good enough for gmp_string_printf. > > I was just wondering whether gmp_vsnprintf supported passing a NULL > buffer like vsnprintf does, and it seems like yes. I tried the > implementation shown below and it works (with gmp 6.2.0 at least). > > I would suggest renaming the function to gmp_string_printf for symmetry > with plain string_printf. > > std::string > gmp_string_asprintf (const char *fmt, ...) > { > va_list vp; > > va_start (vp, fmt); > int size = gmp_vsnprintf (NULL, 0, fmt, vp); > va_end (vp); > > std::string str (size, '\0'); > > /* C++11 and later guarantee std::string uses contiguous memory and > always includes the terminating '\0'. */ > va_start (vp, fmt); > gmp_vsprintf (&str[0], fmt, vp); > va_end (vp); > > return str; > } Thanks for the clear suggestion. We can do the above. I don't know if that's really important in the context of this function which I don't think will be called often, but your suggestion raises a question: Which option should we favor? Allocating a memory region twice, or formatting twice... -- Joel