Pointer arithmetic questions

M

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
 
A

Alvin

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!
 
P

Pete Becker

Alvin said:
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.
 
A

Alvin

Pete said:
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.


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

E. Robert Tisdale

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

James Aguilar

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
 
B

BigBrian

Pete said:
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
 
A

Andrew Koenig

James Aguilar said:
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.
 
M

MOvetsky

E. Robert Tisdale said:
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
 
P

Pete Becker

BigBrian said:
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."
 
P

Pete Becker

James said:
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).
 
U

Uenal Mutlu

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

Old Wolf

Alvin said:
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.
 
B

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
 
B

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
 
R

Ron Natalie

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

Old Wolf

Uenal said:
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)
 
T

Thomas Maier-Komor

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
 
T

Thomas Maier-Komor

Thomas said:
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
 
B

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? :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Arithmetic will null pointer 19
pointer to pointer 3
pointer arithmetic 2
pointer arithmetic 5
pointer arithmetic question. 10
pointer arithmetic and multi-dimensional arrays 5
Pointer question 20
Help with pointers 1

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top