From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16372 invoked by alias); 20 Jun 2011 10:53:10 -0000 Received: (qmail 16363 invoked by uid 22791); 20 Jun 2011 10:53:10 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 10:52:55 +0000 Received: by wwf26 with SMTP id 26so4050443wwf.8 for ; Mon, 20 Jun 2011 03:52:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.174.73 with SMTP id s9mr76086wbz.75.1308567174359; Mon, 20 Jun 2011 03:52:54 -0700 (PDT) Received: by 10.227.28.69 with HTTP; Mon, 20 Jun 2011 03:52:54 -0700 (PDT) In-Reply-To: <4DFB9652.7020107@redhat.com> 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> <20110617141246.GA6164@kam.mff.cuni.cz> <4DFB9652.7020107@redhat.com> Date: Mon, 20 Jun 2011 11:06:00 -0000 Message-ID: Subject: Re: [PATCH PR45098] Disallow NULL pointer in pointer arithmetic From: Richard Guenther To: Jeff Law Cc: Zdenek Dvorak , Tom de Vries , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg01438.txt.bz2 2011/6/17 Jeff Law : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/17/11 08:12, Zdenek Dvorak wrote: > >>>> if we do, we definitely should not -- the only point of such a constru= ction is >>>> to bypass the pointer arithmetics restrictions, >>> >>> Ok, we don't. =A0Where does the C standard say that NULL + 0 is undefin= ed? >> >> I don't think it explicitly states that it is undefined. =A0But 6.5.6 #7= and #8 only >> give semantics for pointers to objects, > Right. =A0I think we need to review the standard closely, but IIRC > pointers are allowed to be NULL, point into an object or point to one > element beyond an object. > > If that's correct P+C could only result in a NULL value if P was one > element beyond the end of an object and C happened to be the exact magic > value to wrap P to zero. =A0I have a hard time seeing how code could which > did that (and relied upon it) could ever be standard conforming. > > Closely related, given P+C where the result is a pointer ought to tells > us that P is non-null since the only way it could be null would be if C > was the exact magic constant to make the result point to a valid object. So you propose we compile the following to an abort()? int __attribute__((noinline)) foo (void *p, int i) { return p + i !=3D NULL; } int main() { if (foo(NULL, 0)) abort (); return 0; } ? Thus, would it be ok to fold ptr + offset =3D=3D/!=3D NULL to false/true? 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?). Richard. > Jeff > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJN+5ZSAAoJEBRtltQi2kC7H34H/RG+9VrV6RqeolgSIqjyLsUf > WbJwl2AWo3xIMt/8OKpWG5zzhgJk67tW+PpSHhzs615kjRPryOiiNq+GBIelteKT > ho3mgbBeU5qJsPLU6j2feBR4+OEdo/oJZxHm/m8zUwWcGuZtazNGtoiuq7rlNr52 > PDl7DM7ZWK731nFZfKYPq/fYMgNxWhxTBo9ucH3s9yXKJ6LYbUGHpKNyP14nB3n3 > bJhdPF8A365uLYz5xCmP0QOKInbzNclN+gbTVZXc+NxtOYNUM16NalsxWhHSALCB > U0S9hpDMDznWWEwPDNdNN2oRphSGmIB0oYxeuaga5RgviNiPNVgEzANkGIv7OEo=3D > =3Dz8kH > -----END PGP SIGNATURE----- >