From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58865 invoked by alias); 18 Mar 2016 00:19:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58851 invoked by uid 89); 18 Mar 2016 00:19:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=47931, claims, talk, outstanding X-HELO: mail-qg0-f49.google.com Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 18 Mar 2016 00:19:05 +0000 Received: by mail-qg0-f49.google.com with SMTP id u110so87047431qge.3 for ; Thu, 17 Mar 2016 17:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EVDAoCAkr/IEJB/aJfrjYx6Gm1bpIppqDhGKzuLOX1E=; b=HrQB/qfN3eOK115Fs6Gb0Vi0J6Tj4YrcYsiJ6ly1/mpYFoGTJExKGCXfXl8K57FpXn kQxILCl3gLuljn8VvDMBc1ICpHt0Y/JnIAkFUAPzqWnDgLYrxtkgo0atB76fePUgnFLv KHUSsga5r2UlOdq//coP9GAMpbNmTuzKMNn51UJqPRT8Vt6tfhFSiJAgu6KoVT3f5+TW y8p0Fcr9ScOE+S9udHiYJspM7ipf3kdXDSC3ictMQOmgk0CzIPazQUgiOXKPhloLnl2l tmqRsJeFDgkmBzeDEla66TTP2GOygJbOa8Jbuq5wB+HOKgykaP7/V0AnL4H8obLs7XvE hTKw== X-Gm-Message-State: AD7BkJIii8wv0Ikg33fHXNFRSc0IZg8oMnlf81oCJ/SycWnkC89b9L0buoQ2s50ZSlKE8w== X-Received: by 10.141.23.211 with SMTP id z202mr14835191qhd.52.1458260343698; Thu, 17 Mar 2016 17:19:03 -0700 (PDT) Received: from [192.168.0.26] (97-122-182-246.hlrn.qwest.net. [97.122.182.246]) by smtp.gmail.com with ESMTPSA id 85sm4926341qkw.19.2016.03.17.17.19.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Mar 2016 17:19:03 -0700 (PDT) Subject: Re: C++ PATCH to fix missing warning (PR c++/70194) To: Jason Merrill , Patrick Palka , Jeff Law References: <20160315104120.GC10006@redhat.com> <20160315105618.GT3017@tucnak.redhat.com> <20160315120918.GD10006@redhat.com> <56E86580.70800@redhat.com> <20160316144552.GG10006@redhat.com> <56E9FDBB.5070903@gmail.com> <56EADB0E.3010304@redhat.com> <56EAFCC6.9010905@gmail.com> <56EAFED5.8090305@redhat.com> Cc: Marek Polacek , Jakub Jelinek , GCC Patches From: Martin Sebor Message-ID: <56EB4975.4080806@gmail.com> Date: Fri, 18 Mar 2016 00:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <56EAFED5.8090305@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg01064.txt.bz2 >> While I would find the warning less misleading if it simply said >> in all three cases: "the address of 'x' will always evaluate as >> ‘true’" I think it would be even more accurate if it said >> "the address of 'x' may be assumed to evaluate to ‘true’" That >> avoids making claims about whether or not it actually is null, >> doesn't talk about the NULL macro when one isn't used in the >> code, and by saying "may assume" it allows for both making >> the assumption as well as not making one. > > That sounds good except that talking about 'true' is wrong when there is > an explicit comparison to a null pointer constant. I'd be fine with > changing "NULL" to "null" or similar. Sounds good. I will use bug 47931 - missing -Waddress warning for comparison with NULL, to take care of the outstanding cases where a warning still isn't issued (in either C++ or C) and also adjust the text of the warning. Martin PS It seems that just adding STRIP_NOPS (op) to Marek's patch significantly increases the number of successfully diagnosed cases. (The small patch I attached to 47931 covers nearly all the remaining cases I could think of.)