2011/6/17 Jeff Law <l...@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-----
>
