From: Jeff Law <law@redhat.com>
To: Zdenek Dvorak <rakdver@kam.mff.cuni.cz>
Cc: Richard Guenther <richard.guenther@gmail.com>,
Tom de Vries <vries@codesourcery.com>,
gcc-patches@gcc.gnu.org
Subject: Re: [PATCH PR45098] Disallow NULL pointer in pointer arithmetic
Date: Fri, 17 Jun 2011 18:24:00 -0000 [thread overview]
Message-ID: <4DFB9652.7020107@redhat.com> (raw)
In-Reply-To: <20110617141246.GA6164@kam.mff.cuni.cz>
-----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.
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-----
next prev parent reply other threads:[~2011-06-17 18:01 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 [this message]
2011-06-20 11:06 ` Richard Guenther
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=4DFB9652.7020107@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rakdver@kam.mff.cuni.cz \
--cc=richard.guenther@gmail.com \
--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).