From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16058 invoked by alias); 17 Jun 2011 11:13:25 -0000 Received: (qmail 16049 invoked by uid 22791); 17 Jun 2011 11:13:24 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Jun 2011 11:13:08 +0000 Received: from localhost (campfire.kam.mff.cuni.cz [195.113.17.153]) by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id 6C0EA9AC788; Fri, 17 Jun 2011 13:13:07 +0200 (CEST) Received: by localhost (Postfix, from userid 29025) id 644C2E336E; Fri, 17 Jun 2011 13:13:07 +0200 (CEST) Date: Fri, 17 Jun 2011 11:22:00 -0000 From: Zdenek Dvorak To: Richard Guenther Cc: Tom de Vries , Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [PATCH PR45098] Disallow NULL pointer in pointer arithmetic Message-ID: <20110617111306.GA26510@kam.mff.cuni.cz> References: <4DF9A526.9060906@codesourcery.com> <4DFA7D1C.9040105@redhat.com> <4DFB2F3A.3040706@codesourcery.com> <20110617105527.GA23535@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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 X-SW-Source: 2011-06/txt/msg01333.txt.bz2 Hi, > >> > Index: tree-vrp.c > >> > =================================================================== > >> > --- tree-vrp.c  (revision 173703) > >> > +++ tree-vrp.c  (working copy) > >> > @@ -2273,7 +2273,12 @@ extract_range_from_binary_expr (value_ra > >> >        { > >> >          /* For pointer types, we are really only interested in asserting > >> >             whether the expression evaluates to non-NULL.  */ > >> > -         if (range_is_nonnull (&vr0) || range_is_nonnull (&vr1)) > >> > +         if (flag_delete_null_pointer_checks && nowrap_type_p (expr_type)) > >> > >> the latter would always return true > >> > >> Btw, I guess you'll "miscompile" a load of code that is strictly > >> undefined.  So I'm not sure we want to do this against our users ... > > > > Probably not, at least unless the user explicitly asks for it -- for example, > > we could have -fdelete-null-pointer-checks=2.  In fact, it might be a good idea > > to implement this flag anyway, since some current uses of flag_delete_null_pointer_checks > > can lead to "miscompilations" when user makes an error in their code and would > > probably appreciate more having their program crash. > > > >> Oh, and of course it's even wrong.  I thing it needs && > >> !range_includes_zero (&vr1) (which we probably don't have).  The > >> offset may be 0 and NULL + 0 > >> is still NULL. > > > > actually, the result of NULL + 0 is undefined (pointer arithmetics is only defined > > for pointers to actual objects, and NULL cannot point to one). > > It's maybe undefined in C, but is it undefined in the middle-end? Thus, > are you sure we never generate it from (void *)((uintptr_t)p + obfuscated_0)? > I'm sure we simply fold that to p + obfuscated_0. if we do, we definitely should not -- the only point of such a construction is to bypass the pointer arithmetics restrictions, Zdenek