Pointer arithmetic questions

[MOvetsky]

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

[Alvin]

MO******@gmail.com 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

[Pete Becker]

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)

[Alvin]

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

[E. Robert Tisdale]

MO******@gmail.com 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?
Your compiler will answer most of these questions.
Next time, please show us the results from your experiments
and convince us that you are *not* just another lazy programmer.

[James Aguilar]

<MO******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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

[BigBrian]

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

[Andrew Koenig]

"James Aguilar" <jf**@cec.wustl.edu> wrote in message
news:d4**********@newsreader.wustl.edu...

<MO******@gmail.com> 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.

[MOvetsky]

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
about it.

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

[Pete Becker]

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]

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)

[Uenal Mutlu]

"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.

[Old Wolf]

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.

[BigBrian]

> 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

[block111]

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

[Ron Natalie]

bl******@mail.ru wrote:

I would really like to know why is it so, please someone explain why?
You've been told why. Please read the messages.
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
of a segment. Because of decades of bad programming assumptions, going
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.

[Old Wolf]

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
when one of its address registers is loaded with an invalid
address, or an address not owned by the current thread.
So when you go (p - 1) you are trying to point to a different
thread's memory, and the CPU immediately kills the thread for
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)

[Thomas Maier-Komor]

bl******@mail.ru 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]

Thomas Maier-Komor wrote:

bl******@mail.ru 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

[block111]

in other words according to the standard
unsigned char* some_random_address = 0xabc12345;
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? :)

[Karl Heinz Buchegger]

bl******@mail.ru wrote:

in other words according to the standard
unsigned char* some_random_address = 0xabc12345;
has undefined behavior becase it doesn't point to an array element or
one past the array...
Exactly
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.
No. It does not mean that you cannot have such a pointer.
It simply means that your compiler or the hardware may do something
strange to that pointer value. You better check your compilers
documentation what it does with that pointer because the language
standard cannot guarantee for anything. Not even that such a pointer
value can be formed.
If programming in asembler there's no
difference wether a pointer points to first, last, arbitrary memory, 0,
0-1 ...

But you are not programming in assembler.
Assembler is by the very nature of it always bound to the CPU
and the operating system you are programming for.
C and C++, as defined in the language standard, free themselfs from
that, so everything CPU and operating system dependent cannot be
guaranteed. That includes if you can form such a pointer and what
derferencing such a pointer leads to.

--
Karl Heinz Buchegger
kb******@gascad.at

[Richard Herring]

In message <11**********************@z14g2000cwz.googlegroups .com>,
bl******@mail.ru writes

in other words according to the standard
unsigned char* some_random_address = 0xabc12345;
has undefined behavior becase it doesn't point to an array element or
one past the array...
.... or a single object. It doesn't have to be an array element.
It simply means that I cannot have a pointer to
an arbitrary element in memory
Yes, you can have a pointer to any actual object in memory...
(even if no such area addressable etc
etc, but I just cannot have an arbitraty address)?,
.... but indeed you can't have a pointer to a random location.
it seems to be very
strange if not ridiculous.
It seems to me to be entirely straightforward and logical. The hardware
may object to you pointing at things you don't own. What you call a
"pointer" may be a segment number and an offset. What's it meant to mean
if that segment doesn't belong to your program, or doesn't exist at all?
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.
That's nothing to do with whether you're programming in assembler or
C++. It's because you only have experience of platforms where these
things don't matter. It makes no difference whether you're programming
in C++ or assembler on architectures where they do, the same problems
will arise.
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.
Doesn't follow. The generated code may not deal properly with special
cases like falling off the end of a segment.
Maybe in C it's ok to do so? :)

--
Richard Herring