From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31572 invoked by alias); 17 Jun 2011 14:13:04 -0000 Received: (qmail 31562 invoked by uid 22791); 17 Jun 2011 14:13:03 -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 14:12:47 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 29025) id A4D0E9AC7EE; Fri, 17 Jun 2011 16:12:46 +0200 (CEST) Date: Fri, 17 Jun 2011 14:57: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: <20110617141246.GA6164@kam.mff.cuni.cz> References: <4DF9A526.9060906@codesourcery.com> <4DFA7D1C.9040105@redhat.com> <4DFB2F3A.3040706@codesourcery.com> <20110617105527.GA23535@kam.mff.cuni.cz> <20110617111306.GA26510@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/msg01342.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, > > Ok, we don't. Where does the C standard say that NULL + 0 is undefined? I don't think it explicitly states that it is undefined. But 6.5.6 #7 and #8 only give semantics for pointers to objects, Zdenek