From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127113 invoked by alias); 28 Feb 2019 14:59:00 -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 127096 invoked by uid 89); 28 Feb 2019 14:59:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=interior, anticipate X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 14:58:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C3779560EB; Thu, 28 Feb 2019 09:58:57 -0500 (EST) 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 1HNSn1Z-18gt; Thu, 28 Feb 2019 09:58:57 -0500 (EST) Received: from murgatroyd (75-166-85-218.hlrn.qwest.net [75.166.85.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id 4D1E2117E05; Thu, 28 Feb 2019 09:58:57 -0500 (EST) From: Tom Tromey To: "Metzger\, Markus T" Cc: Tom Tromey , "gdb-patches\@sourceware.org" Subject: Re: [PATCH 4/7] Add ATTRIBUTE_UNUSED_RESULT to scoped_mmap References: <20190227221814.17661-1-tromey@adacore.com> <20190227221814.17661-5-tromey@adacore.com> Date: Thu, 28 Feb 2019 14:59:00 -0000 In-Reply-To: (Markus T. Metzger's message of "Thu, 28 Feb 2019 07:41:10 +0000") Message-ID: <871s3sx8lr.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-02/txt/msg00564.txt.bz2 >> I don't really see the need for such a change but the patch LGTM. Can we avoid >> the warning by casting the result to void in case it becomes too awkward otherwise? >> E.g. >> (void) data.release (); I'm not sure if that works, but there are other ways to achieve the same thing. >> ...we're storing the base pointer. But we could also store &header->, >> which would make it pretty awkward to use the result of release (). You can do &data.release().field. I agree this could be awkward, but I don't anticipate it happening very much. Holding an interior pointer like that is pretty uncommon, especially in the situation where one must "un-interior-ize" it in order to free the resource. Tom