# Pointer arithmetic questions

Discussion in 'C++' started by MOvetsky@gmail.com, Apr 26, 2005.

1. ### Guest

Is the following code ISO C++ standard compliant?
If yes, is it guaranteed that it will not crash on compliant platforms?
If yes, will it print "Pointers are equal" on any compliant platform?
Will answers be the same if p points to local memory or string literal?

char *p = new char[10];
char *p1 = p-1;
p1 = p1 + 1;

if(p1 == p)
{
cout << "Pointers are equal" << endl;
}

Thank you,

Michael

, Apr 26, 2005

2. ### AlvinGuest

wrote:

> Is the following code ISO C++ standard compliant?
> If yes, is it guaranteed that it will not crash on compliant platforms?
> If yes, will it print "Pointers are equal" on any compliant platform?
> Will answers be the same if p points to local memory or string literal?
>
>
> char *p = new char[10];
> char *p1 = p-1;
> p1 = p1 + 1;
>
> if(p1 == p)
> {
> cout << "Pointers are equal" << endl;
> }
>
> Thank you,
>
> Michael

I would say this is standard compliant (without looking it up). That said,
using p1 before incrementing is undefined (obviously).

Someone correct me if I'm wrong but all that has been done is p1 is set to
1*sizeof(char) before p. I say 1*sizeof(char) because it depends on the
size of a char on the system. For most systems, sizeof(char) is 1; so p1 is
intialised to 1 byte before p. If you use int instead of char, then it
would be 4 bytes (on my 32bit machine) before p.

But you don't need to be concerned with the particulars really, That's the
beauty of pointer arithmetic!

--
Alvin

Alvin, Apr 26, 2005

3. ### Pete BeckerGuest

Alvin wrote:
>
> I would say this is standard compliant (without looking it up).

Then you'd better look it up. <g> The rule for pointer arithmetic is
that you can move around within an array or to one position past the
end. You can't go in front of the beginning.

>
> For most systems, sizeof(char) is 1;
>

sizeof(char) is defined to be 1.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker, Apr 26, 2005
4. ### AlvinGuest

Pete Becker wrote:

> Alvin wrote:
>>
>> I would say this is standard compliant (without looking it up).

>
> Then you'd better look it up. <g> The rule for pointer arithmetic is
> that you can move around within an array or to one position past the
> end. You can't go in front of the beginning.
>
>>
>> For most systems, sizeof(char) is 1;
>>

>
> sizeof(char) is defined to be 1.
>

I guess I didn't make myself clear. By standard compliant I was trying to
say p1 = p-1 was compliant. I didn't intend on saying the result was
compliant.

I guess what you are saying is the act of going in front of the array is
undefined.

--
Alvin

Alvin, Apr 26, 2005
5. ### E. Robert TisdaleGuest

wrote:

> Is the following code

> cat main.cc

#include <iostream>

int main(int argc, char* argv[]) {
char* p = new char[10];
char* p1 = p - 1;
p1 = p1 + 1;

if (p1 == p) {
std::cout << "Pointers are equal." << std::endl;
}

return 0;
}

> g++ -Wall -ansi -pedantic -o main main.cc
> ./main

Pointers are equal.

> ISO C++ standard compliant?

No.

> If yes, is it guaranteed that it will not crash on compliant platforms?

Who would guarantee that compliant code will not crash?

> If yes, will it print "Pointers are equal." on any compliant platform?

It *will* print "Pointers are equal." on *every* compliant platform
even though the code itself is non-compliant.
Nobody guarantees that non-compliant code *will* crash either.

> Will answers be the same if p points to local memory or string literal?

> cat main.cc

#include <iostream>

int main(int argc, char* argv[]) {
const
char* p = "Pointers are equal.";
char* p1 = p - 1;
p1 = p1 + 1;

if (p1 == p) {
std::cout << "Pointers are equal." << std::endl;
}

return 0;
}

> g++ -Wall -ansi -pedantic -o main main.cc

main.cc: In function `int main(int, char**)':
main.cc:6: error: \
invalid conversion from `const char*' to `char*'

Why couldn't you perform this simple experiment yourself?
and convince us that you are *not* just another lazy programmer.

E. Robert Tisdale, Apr 26, 2005
6. ### James AguilarGuest

<> wrote in message
news:...
> Is the following code ISO C++ standard compliant?

It's not compliant, but I'd honestly be amazed if you could find me a
compiler/runtime environment combination that failed to run it and give you the
output you expect.

- JFA1

James Aguilar, Apr 26, 2005
7. ### BigBrianGuest

Pete Becker wrote:
> Then you'd better look it up. <g> The rule for pointer arithmetic is
> that you can move around within an array or to one position past the
> end. You can't go in front of the beginning.
>

Your comment seems to imply that there's something checking the end
points of the array. There is not. You *can* go in front. You can
even do pointer arithmetic on a pointer that's not even pointing to an
array. It compiles, ( but that doesn't mean it doesn't produce
undefined behavior ).

-Brian

BigBrian, Apr 26, 2005
8. ### Andrew KoenigGuest

"James Aguilar" <> wrote in message
news:d4m6c0\$pc2\$...
> <> wrote in message

> It's not compliant, but I'd honestly be amazed if you could find me a
> compiler/runtime environment combination that failed to run it and give
> you the output you expect.

There was an implementation a number of years ago that would terminate such
programs with a diagnostic message. However, I don't think that the company
that produced that implementation is still in business, nor do I know what
other implementations might behave the same way.

Andrew Koenig, Apr 26, 2005
9. ### Guest

E. Robert Tisdale wrote:

> Why couldn't you perform this simple experiment yourself?

Actually I checked it on Visual C++ 6.0 and gcc on Solaris and Linux
and got the expected results.
However, the point of my questions was to figure out if it was a safe
practice to use it on arbitrary platform and what ISO standard said

So from what I hear it is a bad idea to use the code like this for
multi platform development (even though the probability to get in
trouble is low).

Michael

, Apr 26, 2005
10. ### Pete BeckerGuest

BigBrian wrote:

>
> Your comment seems to imply that there's something checking the end
> points of the array.

Nope.

> There is not. You *can* go in front. You can
> even do pointer arithmetic on a pointer that's not even pointing to an
> array. It compiles,

Not necessarily. The behavior is undefined, and that means you cannot
count on anything in particular. There is nothing in the language
definition that requires this code to compile. Don't use compilers to
test code conformance.

By the way, when most people say "you can't to that" there's an implied
"in conforming code."

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker, Apr 26, 2005
11. ### Pete BeckerGuest

James Aguilar wrote:

>
> It's not compliant, but I'd honestly be amazed if you could find me a
> compiler/runtime environment combination that failed to run it and give you the
> output you expect.
>

Win16 with a memory manager that returns blocks in distinct segments;
you can't address below 0 within a segment (it wraps around, and faults
because it's out of range).

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker, Apr 26, 2005
12. ### Uenal MutluGuest

"Pete Becker" wrote
> BigBrian wrote:
>
> >
> > Your comment seems to imply that there's something checking the end
> > points of the array.

>
> Nope.
>
> > There is not. You *can* go in front. You can
> > even do pointer arithmetic on a pointer that's not even pointing to an
> > array. It compiles,

>
> Not necessarily. The behavior is undefined, and that means you cannot
> count on anything in particular. There is nothing in the language
> definition that requires this code to compile. Don't use compilers to
> test code conformance.
>
> By the way, when most people say "you can't to that" there's an implied
> "in conforming code."

Sorry, I don't get it. Why should it not compile? A ptr is just a ptr, it can
point anywhere.

Uenal Mutlu, Apr 27, 2005
13. ### Old WolfGuest

Alvin wrote:
> Pete Becker wrote:
> > Alvin wrote:
> >>
> >> I would say this is standard compliant (without looking it up).

> >
> > Then you'd better look it up. <g> The rule for pointer
> > arithmetic is that you can move around within an array
> > or to one position past the end. You can't go in front
> > of the beginning.

>
> I guess I didn't make myself clear. By standard compliant I was
> trying to say p1 = p-1 was compliant. I didn't intend on saying
> the result was compliant.

The expression (p-1) causes undefined behaviour.

Old Wolf, Apr 27, 2005
14. ### BigBrianGuest

> By the way, when most people say "you can't to that" there's an
implied
> "in conforming code."

I'll try to remember that your messages have an implied "in conforming
code", however, it may be easier if you just include it so there's no
confusion.

-Brian

BigBrian, Apr 27, 2005
15. ### Guest

I can't believe that
char *p1 = p-1; //(1)
p1 = p1 + 1; //(2)
causes undefined behavior as noted by Old Wolf.

I would really like to know why is it so, please someone explain why?

As far as I'm concerned the code is valid if there's substraction and
addition for pointers defined (which is defined). In short
line 1: p1 = address_of(p) - 1*sizeof(*p);
line 2 p1 = address_of(p1) + 1*sizeof(*p1);
how is that phisically may trigger any sort of problem unless generated
code tests result of every pointer operation? Basicly on the first line
p1 is assigned address of the char that precedes (*p) and even if it's
0 why then p1 = 0 should be any different from p1 = p-1???
Even if it wraps in win16 as noted by Pete Becker I still don't
understand what causes segfault?!? The behavior would be surely
undefined if the OP tried to access the char pointed by p1 before line2
was executed. Basicly from machine code it's absolutely valid, but
probably c++ forbids such arithmetics (why?!?)... please explaint
better someone who knows!

Thanks

, Apr 27, 2005
16. ### Ron NatalieGuest

wrote:

> I would really like to know why is it so, please someone explain why?

>
> As far as I'm concerned the code is valid if there's substraction and
> addition for pointers defined (which is defined).

No, it's only defined over the space of a single object. The issue is
machines where there are segments or banks mean a pointer isn't just a
byte offset from the beginning of address space. There's no
requirement that the thing graciously roll negative off the beginning
off by one the other way was deemed to be acceptible.

While C++ puts no bounds on the errors that might come from exploiting
undefined behavior, a very real one is that
(ptr - 1) + 1
doesn't put you back at the original ptr value.

Ron Natalie, Apr 27, 2005
17. ### Old WolfGuest

Uenal Mutlu wrote:
> "Pete Becker" wrote
>> BigBrian wrote:
>>>
>>> Your comment seems to imply that there's something checking the
>>> end points of the array.

>>
>> Nope.
>>
>>> There is not. You *can* go in front. You can
>>> even do pointer arithmetic on a pointer that's not even pointing
>>> to an array. It compiles,

>>
>> Not necessarily. The behavior is undefined, and that means you
>> cannot count on anything in particular. There is nothing in the
>> language definition that requires this code to compile. Don't
>> use compilers to test code conformance.

>
> Sorry, I don't get it. Why should it not compile? A ptr is just
> a ptr, it can point anywhere.

Wrong. A pointer must either be null, indeterminate, or
point to part of an object that exists (or point to a function).

You might be used to some systems (eg. Windows 95) where a pointer
can point anywhere, but that does not apply to all possible systems.

One such example: a CPU could generate a hardware exception
So when you go (p - 1) you are trying to point to a different
an access violation.

Another good example was given by Pete Becker: why should a
system have to do anything sensible if you subtract 1 from
an address of 0 ? What is (1000:0) - 1? (ie. segment 1000 offset 0)

Old Wolf, Apr 27, 2005
18. ### Thomas Maier-KomorGuest

wrote:
> I can't believe that
> char *p1 = p-1; //(1)
> p1 = p1 + 1; //(2)
> causes undefined behavior as noted by Old Wolf.
>
> I would really like to know why is it so, please someone explain why?
>
> As far as I'm concerned the code is valid if there's substraction and
> addition for pointers defined (which is defined). In short
> line 1: p1 = address_of(p) - 1*sizeof(*p);
> line 2 p1 = address_of(p1) + 1*sizeof(*p1);
> how is that phisically may trigger any sort of problem unless generated
> code tests result of every pointer operation? Basicly on the first line
> p1 is assigned address of the char that precedes (*p) and even if it's
> 0 why then p1 = 0 should be any different from p1 = p-1???
> Even if it wraps in win16 as noted by Pete Becker I still don't
> understand what causes segfault?!? The behavior would be surely
> undefined if the OP tried to access the char pointed by p1 before line2
> was executed. Basicly from machine code it's absolutely valid, but
> probably c++ forbids such arithmetics (why?!?)... please explaint
> better someone who knows!
>
> Thanks
>

Read ISO9899:1999 section 6.5.6 paragraph 8:

<quote>
When an expression that has integer type is added to or subtracted from
a pointer, the
result has the type of the pointer operand. If the pointer operand
points to an element of
an array object, and the array is large enough, the result points to an
element offset from
the original element such that the difference of the subscripts of the
resulting and original
array elements equals the integer expression. In other words, if the
expression P points to
the i-th element of an array object, the expressions (P)+N
(equivalently, N+(P)) and
(P)-N (where N has the value n) point to, respectively, the i+n-th and
iâˆ’n-th elements of
the array object, provided they exist. Moreover, if the expression P
points to the last
element of an array object, the expression (P)+1 points one past the
last element of the
array object, and if the expression Q points one past the last element
of an array object,
the expression (Q)-1 points to the last element of the array object. If
both the pointer
operand and the result point to elements of the same array object, or
one past the last
element of the array object, the evaluation shall not produce an
overflow; otherwise, the
behavior is undefined. If the result points one past the last element of
the array object, it
shall not be used as the operand of a unary * operator that is evaluated.
</quote>

especially the last two sentences...

Tom

Thomas Maier-Komor, Apr 27, 2005
19. ### Thomas Maier-KomorGuest

Thomas Maier-Komor wrote:
> wrote:
>
>> I can't believe that
>> char *p1 = p-1; //(1)
>> p1 = p1 + 1; //(2)
>> causes undefined behavior as noted by Old Wolf.
>>
>> I would really like to know why is it so, please someone explain why?
>>
>> As far as I'm concerned the code is valid if there's substraction and
>> addition for pointers defined (which is defined). In short
>> line 1: p1 = address_of(p) - 1*sizeof(*p);
>> line 2 p1 = address_of(p1) + 1*sizeof(*p1);
>> how is that phisically may trigger any sort of problem unless generated
>> code tests result of every pointer operation? Basicly on the first line
>> p1 is assigned address of the char that precedes (*p) and even if it's
>> 0 why then p1 = 0 should be any different from p1 = p-1???
>> Even if it wraps in win16 as noted by Pete Becker I still don't
>> understand what causes segfault?!? The behavior would be surely
>> undefined if the OP tried to access the char pointed by p1 before line2
>> was executed. Basicly from machine code it's absolutely valid, but
>> probably c++ forbids such arithmetics (why?!?)... please explaint
>> better someone who knows!
>>
>> Thanks
>>

>
> Read ISO9899:1999 section 6.5.6 paragraph 8:
>
> <quote>
> When an expression that has integer type is added to or subtracted from
> a pointer, the
> result has the type of the pointer operand. If the pointer operand
> points to an element of
> an array object, and the array is large enough, the result points to an
> element offset from
> the original element such that the difference of the subscripts of the
> resulting and original
> array elements equals the integer expression. In other words, if the
> expression P points to
> the i-th element of an array object, the expressions (P)+N
> (equivalently, N+(P)) and
> (P)-N (where N has the value n) point to, respectively, the i+n-th and
> iâˆ’n-th elements of
> the array object, provided they exist. Moreover, if the expression P
> points to the last
> element of an array object, the expression (P)+1 points one past the
> last element of the
> array object, and if the expression Q points one past the last element
> of an array object,
> the expression (Q)-1 points to the last element of the array object. If
> both the pointer
> operand and the result point to elements of the same array object, or
> one past the last
> element of the array object, the evaluation shall not produce an
> overflow; otherwise, the
> behavior is undefined. If the result points one past the last element of
> the array object, it
> shall not be used as the operand of a unary * operator that is evaluated.
> </quote>
>
> especially the last two sentences...
>
> Tom

sorry that was the wrong standard...
but in ISO14882 section 5.7 paragraph 5 the text is almost the same:

<quote>
When an expression that has integral type is added to or subtracted from
a pointer, the result has the type of
the pointer operand. If the pointer operand points to an element of an
array object, and the array is large
enough, the result points to an element offset from the original element
such that the difference of the subscripts
of the resulting and original array elements equals the integral
expression. In other words, if the
expression P points to the i-th element of an array object, the
expressions (P)+N (equivalently, N+(P))
and (P)-N (where N has the value n) point to, respectively, the i+n-th
and iâ€“n-th elements of the array
object, provided they exist. Moreover, if the expression P points to the
last element of an array object, the
expression (P)+1 points one past the last element of the array object,
and if the expression Q points one
past the last element of an array object, the expression (Q)-1 points to
the last element of the array object.
If both the pointer operand and the result point to elements of the same
array object, or one past the last element
of the array object, the evaluation shall not produce an overflow;
otherwise, the behavior is undefined.
</quote>

Tom

Thomas Maier-Komor, Apr 27, 2005
20. ### Guest

in other words according to the standard
has undefined behavior becase it doesn't point to an array element or
one past the array... It simply means that I cannot have a pointer to
an arbitrary element in memory (even if no such area addressable etc
etc, but I just cannot have an arbitraty address)?, it seems to be very
strange if not ridiculous. If programming in asembler there's no
difference wether a pointer points to first, last, arbitrary memory, 0,
0-1 ... all comes up when you access this regions by the pointer.
It's very surprising for me to know about that, thanks for the info
Tom.

ps. anyways, I can't believe that the code of original poster could
have any other behavior than printing that the pointers are equal. Even
it's win16 or whatever as long as the generated code doesn't checks the
result of every pointer operation not to point to arbitrary memory then
it should not have any problems. Maybe in C it's ok to do so?

, Apr 27, 2005