public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Richard Guenther <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][C] Fixup pointer-int-sum
Date: Thu, 07 Jul 2011 14:56:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.1107071442400.5437@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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

  reply	other threads:[~2011-07-07 14:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-07 11:44 Richard Guenther
2011-07-07 14:56 ` Joseph S. Myers [this message]
2011-07-07 15:02   ` Richard Guenther

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=Pine.LNX.4.64.1107071442400.5437@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).