public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Guenther <richard.guenther@gmail.com>
To: Jeff Law <law@redhat.com>
Cc: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>,
	Tom de Vries <vries@codesourcery.com>,
		gcc-patches@gcc.gnu.org
Subject: Re: [PATCH PR45098] Disallow NULL pointer in pointer arithmetic
Date: Mon, 20 Jun 2011 11:06:00 -0000	[thread overview]
Message-ID: <BANLkTinyFA4MEoxcec2HE91YmWLWXSJKyQ@mail.gmail.com> (raw)
In-Reply-To: <4DFB9652.7020107@redhat.com>

2011/6/17 Jeff Law <law@redhat.com>:
> -----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 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,
> Right.  I 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.  I 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 != NULL;
}
int main()
{
  if (foo(NULL, 0))
    abort ();
  return 0;
}

?  Thus, would it be ok to fold ptr + offset ==/!= 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=
> =z8kH
> -----END PGP SIGNATURE-----
>

  reply	other threads:[~2011-06-20 10:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16  6:42 Tom de Vries
2011-06-16  6:51 ` Tom de Vries
2011-06-16  7:34 ` Zdenek Dvorak
2011-06-16 12:22   ` Tom de Vries
2011-06-16 15:33     ` Zdenek Dvorak
2011-06-16 15:42       ` Richard Guenther
2011-06-16 15:54         ` Zdenek Dvorak
2011-06-16 18:10           ` Tom de Vries
2011-06-16 22:03 ` Jeff Law
2011-06-17 10:44   ` Tom de Vries
2011-06-17 10:56     ` Richard Guenther
2011-06-17 10:57       ` Zdenek Dvorak
2011-06-17 11:13         ` Richard Guenther
2011-06-17 11:22           ` Zdenek Dvorak
2011-06-17 13:01             ` Richard Guenther
2011-06-17 14:57               ` Zdenek Dvorak
2011-06-17 18:24                 ` Jeff Law
2011-06-20 11:06                   ` Richard Guenther [this message]
2011-06-20 12:26                     ` Zdenek Dvorak
2011-06-20 12:41                       ` Zdenek Dvorak
2011-06-20 13:29                         ` Richard Guenther
2011-06-20 13:35                           ` Michael Matz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTinyFA4MEoxcec2HE91YmWLWXSJKyQ@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=rakdver@kam.mff.cuni.cz \
    --cc=vries@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).