Pointer arithmetic questions

[Karl Heinz Buchegger]

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.

 

[Richard Herring]

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.