From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21363 invoked by alias); 20 Jun 2011 12:26:15 -0000 Received: (qmail 21337 invoked by uid 22791); 20 Jun 2011 12:26:12 -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; Mon, 20 Jun 2011 12:25:21 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 29025) id 9BCDA9AC75C; Mon, 20 Jun 2011 14:25:19 +0200 (CEST) Date: Mon, 20 Jun 2011 12:41:00 -0000 From: Zdenek Dvorak To: Richard Guenther Cc: Jeff Law , Tom de Vries , gcc-patches@gcc.gnu.org Subject: Re: [PATCH PR45098] Disallow NULL pointer in pointer arithmetic Message-ID: <20110620122519.GA16457@kam.mff.cuni.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110620122036.GA11662@kam.mff.cuni.cz> 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/msg01453.txt.bz2 > > I don't think we should move this kind of undefinedness from C to > > the GIMPLE semantics. What do other languages allow that > > we have to support (what did K&R C specify?). > > I don't think there is a formal specification of K&R C, just the (somewhat > informal) book. On topic of pointer arithmetics, the case of addition > is not completely clear. It does say that you can only subtract pointers > to members of the same array, though. > > On topic of addition of integer to a pointer, it says that "The construction > p + n means the address of the n-th object beyond the one p currently points to. This is true > regardless of the kind of object p points to; n is scaled according to the size of the objects p > points to, which is determined by the declaration of p." Anyway, I don't think that this should be a matter of lawyer scrutiny 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. Zdenek