public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/27214] The C frontend introduces undefined pointer overflow
Date: Wed, 19 Apr 2006 17:15:00 -0000	[thread overview]
Message-ID: <20060419171514.6887.qmail@sourceware.org> (raw)
In-Reply-To: <bug-27214-10053@http.gcc.gnu.org/bugzilla/>



------- Comment #7 from joseph at codesourcery dot com  2006-04-19 17:15 -------
Subject: Re:  The C frontend introduces undefined pointer overflow

On Wed, 19 Apr 2006, rakdver at gcc dot gnu dot org wrote:

> Andrew, please do not mark PRs as invalid until the people involved in the
> discussion do not agree on the common interpretation of the standard.

This bug is about the interpretation of GCC's internal representation, not 
that of the standard.

Valid pointer offsets range from -SIZE_MAX to +SIZE_MAX - thus they 
require one bit more than pointers to store.  An internal representation 
not allowing for this range of offsets is problematic.

(As for the C language issues, subtraction of two pointers involves 
undefined behavior if the result is outside the range PTRDIFF_MIN to 
PTRDIFF_MAX, but you can still have an array using more than half of 
memory as long as you don't subtract pointers to elements too far apart.  
You could also have an array using almost all of memory, and subtract 
elements at opposite ends, as long as the element size is not 1; only the 
final result needs to be in range.  Such subtraction of pointers more 
than half of memory apart is not however an important case, and probably 
not one it's feasible to get right efficiently.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214


  parent reply	other threads:[~2006-04-19 17:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-19 11:44 [Bug c/27214] New: " rguenth at gcc dot gnu dot org
2006-04-19 15:06 ` [Bug c/27214] " pinskia at gcc dot gnu dot org
2006-04-19 15:13 ` rguenth at gcc dot gnu dot org
2006-04-19 15:22 ` pinskia at gcc dot gnu dot org
2006-04-19 15:31 ` rguenth at gcc dot gnu dot org
2006-04-19 15:34 ` pinskia at gcc dot gnu dot org
2006-04-19 16:32 ` rakdver at gcc dot gnu dot org
2006-04-19 17:15 ` joseph at codesourcery dot com [this message]
2006-05-05  9:23 ` pinskia at gcc dot gnu dot org
2007-12-11  0:46 ` pinskia at gcc dot gnu dot org
2008-01-03 16:25 ` rguenth at gcc dot gnu dot org
     [not found] <bug-27214-4@http.gcc.gnu.org/bugzilla/>
2012-05-06  4:23 ` bugdal at aerifal dot cx
2012-05-07  9:21 ` rguenth at gcc dot gnu.org
2021-03-25 14:11 ` rguenth at gcc dot gnu.org

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=20060419171514.6887.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).