From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EDZlD0nLwl9fdAAAWB0awg (envelope-from ) for ; Sat, 28 Nov 2020 17:12:25 -0500 Received: by simark.ca (Postfix, from userid 112) id 329DA1F0AB; Sat, 28 Nov 2020 17:12:25 -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=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 (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A359A1E590 for ; Sat, 28 Nov 2020 17:12:24 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 488233857C4C; Sat, 28 Nov 2020 22:12:24 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 93C373858004 for ; Sat, 28 Nov 2020 22:12:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 93C373858004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2FF301E590; Sat, 28 Nov 2020 17:12:22 -0500 (EST) Subject: Re: [PATCH v2] Search for DWZ files in debug-file-directories as well To: Sergio Durigan Junior References: <20201114234842.2334396-1-sergiodj@sergiodj.net> <20201119022708.3627287-1-sergiodj@sergiodj.net> <87zh31yza7.fsf@paluero> From: Simon Marchi Message-ID: Date: Sat, 28 Nov 2020 17:12:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <87zh31yza7.fsf@paluero> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit 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: Mark Wielaard , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-11-28 3:58 p.m., Sergio Durigan Junior wrote: >> I think it would be more readable and efficient (less bytes copied >> around) to do just build the new_filename string with something like: >> >> std::string new_filename = debugdir + &filename[dwz_pos]; >> >> This is untested, but I think you'll get the point. &filename[dwz_pos] >> could also be put into a variable with a meaningful name, for clarity >> (though I can't think of a good name right now). > > It is more efficient, but using .erase + .insert can be more readable. > But OK, I don't have a strong opinion here. Well, I suggested the other way because I think that is more readable :). I see it more as "the new path is made of this part plus that part". I'll let you choose what you prefer, it's not code that needs to be extremely optimized anyway. >> And we probably don't need the allocated `ddir` std::string, you >> construct it but never really use it (you could just refer to debugdir). > > I'll need it for the new version of the code, which will implement the > idea I gave above (always guaranteeing that ddir ends with > DIR_SEPARATOR). Ok, if you do that I think you can move ddir out of the loop, it doesn't need to be re-computed for each loop iteration. Simon