From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3491 invoked by alias); 9 Nov 2016 23:20:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3481 invoked by uid 89); 9 Nov 2016 23:20:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=lived, rfa, RFA, Hx-languages-length:962 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Nov 2016 23:20:36 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 82F6E9023B; Wed, 9 Nov 2016 23:20:35 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA9NKYLl025780; Wed, 9 Nov 2016 18:20:34 -0500 Subject: Re: [RFA] Use unique_xmalloc_ptr in Python code To: Tom Tromey , gdb-patches@sourceware.org References: <1478292124-26362-1-git-send-email-tom@tromey.com> From: Pedro Alves Message-ID: <71852739-1e5c-6be8-eb21-822c67bc0ea9@redhat.com> Date: Wed, 09 Nov 2016 23:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1478292124-26362-1-git-send-email-tom@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00240.txt.bz2 On 11/04/2016 08:42 PM, Tom Tromey wrote: > This changes some utility functions in the Python code to return > unique_xmalloc_ptr, and then fixes up the callers. > > I chose unique_xmalloc_ptr rather than std::string because at a few > call points the xmalloc'd string is released and ownership transferred > elsewhere. IMO, for simplicity sake, we should default to use std::string, unless we're ending up storing the result in some long lived objects where memory really is a concern (because of many instances), and a final string dup/copy to destination wouldn't be too heavy too. I doubt that's the case here, but it's not easy to see without trying. Did you try a std::string approach first? In any case, this is strictly an improvement, so OK with me. Please push. Let's get this out of the way of your py-ref series. We can convert to std::string at some other point, if desirable. Thanks, Pedro Alves