This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][C] Fixup pointer-int-sum
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 7 Jul 2011 14:51:29 +0000 (UTC)
- Subject: Re: [PATCH][C] Fixup pointer-int-sum
- References: <alpine.LNX.2.00.1107071332580.810@zhemvz.fhfr.qr>
On Thu, 7 Jul 2011, Richard Guenther wrote:
> not overflow (what is actually the C semantics - is the
> multiplication allowed to overflow for unsigned intop? If not
Overflow is not allowed. Formally the multiplication is as-if to infinite
precision, and then there is undefined behavior if the result of the
addition (to infinite precision) is outside the array pointed to -
wrapping around by some multiple of the whole address space is not
allowed.
In practice, as previously discussed objects half or more of the address
space do not work reliably because of the problems doing pointer
subtraction, so always using a signed type shouldn't break anything that
actually worked reliably (though how unreliable things were with large
malloced objects - which unfortunately glibc's malloc can provide - if the
source code didn't use pointer subtraction, I don't know).
In GCC's terms half or more of the address space generally means half the
range of size_t. (m32c has ptrdiff_t wider than size_t in some cases. On
such unusual architectures it ought to be possible to have objects whose
size is up to SIZE_MAX bytes and have pointer addition and subtraction
work reliably, which would suggest using ptrdiff_t for arithmetic in such
cases, but the code checking sizes for arrays of constant size uses the
signed type corresponding to size_t, so you could only get a larger object
through malloc or VLAs.)
The patch is OK. Unconditionally signed is also OK, though I don't see
any advantage over this version.
--
Joseph S. Myers
joseph@codesourcery.com