This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR 25512: pointer overflow defined?
Richard Guenther wrote:
On Wed, 21 Dec 2005, Andrew Haley wrote:
Richard Guenther writes:
>
> The problem in this PR is that code like in the testcase (from
> OpenOffice) assumes that pointer overflow is defined. As the
> standard does not talk about wrapping pointer semantics at all (at
> least I couldn't find anything about that), how should we treat
> this?
Look at Section 6.5.6, Para 8. The code is undefined.
This talks about pointers that point to elements of an array object.
It does not talk about doing arithmetic on arbitrary pointer (constants),
which is what the code does.
Right, but that's the point. "doing arithmetic on arbitrary pointer"
values is
not defined, it is not even defined to compare two pointers pointing to two
different objects.
Alex Stepanov noted to me once that he preferred Ada to C, since in Ada
general pointer arithmetic was available and it is not in C (in Ada you can
use the type Integer_Address which works as intended).
Of course in practice general pointer arithmetic works in C, but gcc takes
a very aggressive attitude to undefined code, and when code like this fails
is content to cite chapter and verse of the standard saying the code is
undefined (personally I think gcc is too aggressive in this regard, but
I guess you have the freedom to take that attitude if you are not in the
commercial business of satisfying paying customers :-)
Or is a pointer always pointing to elements
of some array object (being it the global heap "array object")?
There is no such thing in C as the "global heap array object", you can
only compare or do arithmeitc on pointers that are within a single
array object.
One way to think about the semantic model is to consider pointers
in C to consist of a base/offset pair, where the base points to the
start of the object (some debugging checkout C compilers even
use such a format). Then operations on pointers need ONLY
reference the offset.
Note that this was more than a theory in some C compilers operating
in large (multi-segment) mode on the 286, where indeed pointers
were in base offset (well segment/offset) form, and pointer
arithmetic could just deal with the offset.
Richard.