https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> The desired cleanup is to make POINTER_PLUS_EXPR take a signed offset
> argument,
> aka ssizetype instead of sizetype.
>
> Bin was working on this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
Rich Felker bugdal at aerifal dot cx changed:
What|Removed |Added
CC||bugdal at aerifal
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-03 15:54
---
Fixed only in the sense that we now create
pointer_plus_expr 0x2b6e7ed3b1c0
type pointer_type 0x2b6e7eda3000
type integer_type 0x2b6e7ed8c300 char public string-flag QI
size integer_cst
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-12-11 00:45 ---
I think this has been fixed by the pointer plus branch merge for 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 09:22 ---
Maybe it is time to add POINTER_PLUS_EXPR which should solve the problem (well
95% of the way as what is the type of the 2nd operand, a signed or unsigned
type).
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 15:06 ---
There is no wrapping here or undefinedness here as far as I can see
You just have to learn that a + -CST is the same as a - CST.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-19 15:13 ---
-CST in this case is unsigned 4294967292, it just happens to be printed as
-4B.
So the addition wraps, as it is done using unsigned arithmetic. Writing
char *foo(char *p)
{
return p + 4294967292;
}
results in
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-19 15:22 ---
Both are those are the same. Maybe we should just get a POINTER_PLUS_EXPR but
that is really not an issue here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-19 15:31 ---
How's that the same? Either you say that pointers follow unsigned integer
types in overflow behavior (quote me the standard for that) or explain why
p + -4 is treated as p + (char *)-4
but p - 4 is
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-19 15:34 ---
Then p + -4 is overflowed already -4 is no different than the unsigned version.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-19 16:32 ---
I do not think this PR is invalid:
int a[100];
int *p = a[50];
p - 1 is well defined, and points to 50 - 1 th element of a, as standard
specifies
p + (-1) is also well defined, and points to 50 + (-1) th element,
--- 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
15 matches
Mail list logo
