From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 716B5389545C; Tue, 19 May 2020 17:26:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 716B5389545C 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.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id CE0E91E79B; Tue, 19 May 2020 13:26:58 -0400 (EDT) Subject: Re: PR25993, read of freed memory To: Christian Biesinger Cc: Alan Modra , binutils@sourceware.org, gdb-patches References: <20200519043205.GT1088@bubble.grove.modra.org> <111d8c5d-d615-e0ae-36de-519c43a51139@simark.ca> From: Simon Marchi Message-ID: Date: Tue, 19 May 2020 13:26:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 19 May 2020 17:27:00 -0000 On 2020-05-19 1:25 p.m., Christian Biesinger wrote: > On Tue, May 19, 2020 at 8:27 AM Simon Marchi wrote: >> Can you please change `char *name` to be `gdb::optional`? >> >> The caller that passes a name should use string_printf to build the string, as mentioned >> above. The caller that does not pass a name can pass `{}`, to pass an empty optional. > > We may want to add C++17's std::nullopt to gdb::optional, to make it > clearer what's going on there. Then you could pass gdb::nullopt > instead of {}. If it's technically possible, I completely agree. Simon