From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31516 invoked by alias); 20 Jun 2011 13:29:28 -0000 Received: (qmail 31398 invoked by uid 22791); 20 Jun 2011 13:29:27 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 13:29:11 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 4C8F094430; Mon, 20 Jun 2011 15:29:10 +0200 (CEST) Date: Mon, 20 Jun 2011 13:35:00 -0000 From: Michael Matz To: Richard Guenther Cc: Zdenek Dvorak , Jeff Law , Tom de Vries , gcc-patches@gcc.gnu.org Subject: Re: [PATCH PR45098] Disallow NULL pointer in pointer arithmetic In-Reply-To: Message-ID: References: <4DFB2F3A.3040706@codesourcery.com> <20110617105527.GA23535@kam.mff.cuni.cz> <20110617111306.GA26510@kam.mff.cuni.cz> <20110617141246.GA6164@kam.mff.cuni.cz> <4DFB9652.7020107@redhat.com> <20110620122036.GA11662@kam.mff.cuni.cz> <20110620122519.GA16457@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168427776-1749133763-1308576549=:17115" X-IsSubscribed: yes 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/msg01458.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --168427776-1749133763-1308576549=:17115 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-length: 1355 Hi, On Mon, 20 Jun 2011, Richard Guenther wrote: > > of the specifications; rather, we should consider whether there is a > > situation where a user could reasonably expect NULL + 0 to be valid. > >  In the example by Richard, > > > > int __attribute__((noinline)) foo (void *p, int i) > > { > >  return p + i != NULL; > > } > > > > I think it would be hard to argue that this construction is natural. > > Nor does it feel natural that 'p' is different from 'p + 0'. Right. If we would include such reasoning in GIMPLE, we already could infer simply from the presence of any POINTER_PLUS_EXPR that the pointer operand is != NULL (which means != zero-bit-pattern in our case) in the control region containing it. This might be tempting, but it would be quite confusing, and I'm not sure at all that we should include such reasoning for an IR that is supposed to be able to implement all languages, which in my book would include languages that simply define pointers as addresses in a wrapping space. Hence, if the language in question does guarantee certain specifics (here non-null of p in 'p + i'), it should explicitely say so via assert_expr. Possibly this doesn't work currently that well, because we recompute and throw away assert_exprs sometimes, but I argue that we should work towards making this possible. Ciao, Michael. --168427776-1749133763-1308576549=:17115--