Address Arithmetic

[aistone]

Hi all,

If I compile the following program with G++ 4.0.2 and run it I get the
following output:

#include <iostream>
using namespace std;

int main(char argc, char *argv[]) {
int x, y;

cout << "Address of x = " << (unsigned long)&x << endl;
cout << "Address of y = " << (unsigned long)&y << endl;
cout << "Difference in addresses = "
<< (unsigned long)&y - (unsigned long)&x << endl;

return 1;
}

$ ./a.out
Address of x = 3219613408
Address of y = 3219613404
Difference in addresses = 4294967292

I'm wondering why does "Difference in addresses" show a long, seemingly
random, number instead of 4? Am I casting things wrong?

Thanks,
-Andy

[aistone]

Acck! I should review my problems longer before submitting them to
UseNet :-(. For some reason y is allocated before x in the address
space. Doing arithmatic on the unsigned values underflows and a "big"
value is produced.

Never mind.
-Andy

[e-mail] wrote:

Hi all,

If I compile the following program with G++ 4.0.2 and run it I get the
following output:

#include <iostream>
using namespace std;

int main(char argc, char *argv[]) {
int x, y;

cout << "Address of x = " << (unsigned long)&x << endl;
cout << "Address of y = " << (unsigned long)&y << endl;
cout << "Difference in addresses = "
<< (unsigned long)&y - (unsigned long)&x << endl;

return 1;
}

$ ./a.out
Address of x = 3219613408
Address of y = 3219613404
Difference in addresses = 4294967292

I'm wondering why does "Difference in addresses" show a long, seemingly
random, number instead of 4? Am I casting things wrong?

Thanks,
-Andy

[Ian Collins]

ai*****@gmail.com wrote:

Acck! I should review my problems longer before submitting them to
UseNet :-(. For some reason y is allocated before x in the address
space. Doing arithmatic on the unsigned values underflows and a "big"
value is produced.

Framing a post to Usenet is often a good way to solve you own problems!

--
Ian Collins.

[Eric Jensen]

<ai*****@gmail.comskrev i en meddelelse
news:11**********************@m73g2000cwd.googlegr oups.com...

Hi all,

If I compile the following program with G++ 4.0.2 and run it I get the
following output:

#include <iostream>
using namespace std;

int main(char argc, char *argv[]) {
int x, y;

cout << "Address of x = " << (unsigned long)&x << endl;
cout << "Address of y = " << (unsigned long)&y << endl;
cout << "Difference in addresses = "
<< (unsigned long)&y - (unsigned long)&x << endl;

return 1;
}

$ ./a.out
Address of x = 3219613408
Address of y = 3219613404
Difference in addresses = 4294967292

I'm wondering why does "Difference in addresses" show a long, seemingly
random, number instead of 4? Am I casting things wrong?

Because you assume that the address of pointer y is greater than pointer x.

On the win32 platform your cast will result in pointer turncation, most
likely also on linux.
You need to cast to a 64 bit number instead of a 32 bit number.

If you change your cast to (unsigned long long) it will work fine on atleast
win32.

int x, y;
unsigned long long addrOfX = reinterpret_cast<unsigned long long>(&x),
addrOfY = reinterpret_cast<unsigned long
long>(&y);
cout << "Address of x = " << addrOfX << endl <<
"Address of y = " << addrOfY << endl <<
"Difference in addresses = " <<
(addrOfX < addrOfY ? (addrOfY - addrOfX) : (addrOfX - addrOfY))
<< endl;

//eric

[Frederick Gotham]

posted:

I'm wondering why does "Difference in addresses" show a long, seemingly
random, number instead of 4? Am I casting things wrong?

Perhaps you want something like:

#include <stdio.h>
#include <stddef.h>

typedef int SomeType;

int main(void)
{
SomeType const obj[2];

ptrdiff_t const diff = (char*)(obj + 1) - (char*)obj;

printf("The difference is %lu bytes.\n", diff);
}

(Would "ptrdiff_t" be preferable over "size_t"? Is "%lu" suitable to use
with "printf"?)
When you define two objects of the same type as follows:

int a, b;

You have no guarantee that there is no padding between them, or even that
they're stored ANYWHERE near each other in memory.

--

Frederick Gotham

[Frederick Gotham]

Frederick Gotham posted:
I forgot I was on the C++ forum, rather than C.

#include <stdio.h>
#include <stddef.h>

#include <iostream>
#include <cstddef>

typedef int SomeType;

int main(void)
{
SomeType const obj[2];

ptrdiff_t const diff = (char*)(obj + 1) - (char*)obj;

std::ptrdiff_t

printf("The difference is %lu bytes.\n", diff);

std::cout << ...
--

Frederick Gotham

[Robbie Hatley]

<ai*****@gmail.comwrote:

cout << "Difference in addresses = "
<< (unsigned long)&y - (unsigned long)&x << endl;

Address of x = 3219613408
Address of y = 3219613404
Difference in addresses = 4294967292

I'm wondering why does "Difference in addresses" show a long,
seemingly random, number instead of 4?

(uint32)(4 - 8) = (uint32) (-4)
= 2^32 - 4
= 4294967296 - 4
= 4294967292

Which is exactly what you got.
--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/

[Jack Klein]

On Thu, 06 Jul 2006 23:40:43 GMT, Frederick Gotham
<fg*******@SPAM.comwrote in comp.lang.c++:

Frederick Gotham posted:
I forgot I was on the C++ forum, rather than C.

#include <stdio.h>
#include <stddef.h>

#include <iostream>
#include <cstddef>

typedef int SomeType;

int main(void)
{
SomeType const obj[2];

ptrdiff_t const diff = (char*)(obj + 1) - (char*)obj;

Subtracting pointers that do not point to parts of the same object is
undefined behavior.

>

std::ptrdiff_t

printf("The difference is %lu bytes.\n", diff);

std::cout << ...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Thu, 06 Jul 2006 23:37:40 GMT, Frederick Gotham
<fg*******@SPAM.comwrote in comp.lang.c++:

posted:

I'm wondering why does "Difference in addresses" show a long, seemingly
random, number instead of 4? Am I casting things wrong?

Perhaps you want something like:

#include <stdio.h>
#include <stddef.h>

typedef int SomeType;

int main(void)
{
SomeType const obj[2];

ptrdiff_t const diff = (char*)(obj + 1) - (char*)obj;

Subtracting or comparing pointers that do not point to parts of the
same object is undefined behavior.

printf("The difference is %lu bytes.\n", diff);
}

(Would "ptrdiff_t" be preferable over "size_t"? Is "%lu" suitable to use
with "printf"?)

ptrdiff_t is a signed type. There is no guarantee whatsoever what, if
any, relationship it might have with an unsigned long, so "%lu" is
particularly inappropriate. In fact, it needs a cast to whatever type
of printf() conversion specified is used.

When you define two objects of the same type as follows:

int a, b;

You have no guarantee that there is no padding between them, or even that
they're stored ANYWHERE near each other in memory.

That's why subtracting or comparing their addresses is strictly
undefined.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jerry Coffin]

In article <7j********************************@4ax.com>,
ja*******@spamcop.net says...

[ ... ]

Subtracting or comparing pointers that do not point to parts of the
same object is undefined behavior.

Close, but not quite right. The behavior is defined, but the result
is unspecified. If you do something like this:

int a, b;

if ( a < b)
std::cout << "A less than B";
else
std::cout << "A greater than or equal to B";

It's entirely open to question _which_ leg of the if statement will
execute, but you basically get normal execution: one leg or the other
will execute, and things proceed normally from there. Undefined
behavior would mean absolutely _anything_ could happen from there
out.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Alf P. Steinbach]

* Jerry Coffin:

In article <7j********************************@4ax.com>,
ja*******@spamcop.net says...

[ ... ]

>Subtracting or comparing pointers that do not point to parts of the
same object is undefined behavior.

Close, but not quite right. The behavior is defined, but the result
is unspecified. If you do something like this:

int a, b;

if ( a < b)
std::cout << "A less than B";
else
std::cout << "A greater than or equal to B";

It's entirely open to question _which_ leg of the if statement will
execute, but you basically get normal execution: one leg or the other
will execute, and things proceed normally from there. Undefined
behavior would mean absolutely _anything_ could happen from there
out.

Not sure about that and right now I don't feel like checking it out;
however, I'm writing to point out that the /standard library/ provides
functions to compare unrelated pointers safely.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ron Natalie]

Alf P. Steinbach wrote:

>
Not sure about that and right now I don't feel like checking it out;
however, I'm writing to point out that the /standard library/ provides
functions to compare unrelated pointers safely.

Really?

The original poster was quite right. The line from the standard
explicitly defines unspecified result:

If two pointers p and q of the same type point to different objects
that are not members of the same object or elements of the same array
or to different functions, or if only one of them is null, the
results of p<q, p>q, p<=q, and p>=q are unspecified.
I don't know what you mean by the quoted passage above. But I don't
believe there is anything in the library that provides any stricter
ordering on unrelated pointers that my passage above (from 5.9 of the
standard).

[Alf P. Steinbach]

* Ron Natalie:

Alf P. Steinbach wrote:

>>
Not sure about that and right now I don't feel like checking it out;
however, I'm writing to point out that the /standard library/ provides
functions to compare unrelated pointers safely.

Really?

Yep.

The original poster was quite right. The line from the standard
explicitly defines unspecified result:

If two pointers p and q of the same type point to different objects
that are not members of the same object or elements of the same array
or to different functions, or if only one of them is null, the
results of p<q, p>q, p<=q, and p>=q are unspecified.

That means /unspecified/, not undefined, as Jack wrote. So Jerry was
right, and Jack was wrong; what the OP was, I don't know. Thanks for
doing what I didn't have time to do (looking this up in the standard).

I don't know what you mean by the quoted passage above. But I don't
believe there is anything in the library that provides any stricter
ordering on unrelated pointers that my passage above (from 5.9 of the
standard).

std::less & family.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ron Natalie]

Alf P. Steinbach wrote:

>
That means /unspecified/, not undefined, as Jack wrote. So Jerry was
right, and Jack was wrong; what the OP was, I don't know. Thanks for
doing what I didn't have time to do (looking this up in the standard).

Your followup was to Jerry Coffin's correction to Jack (which did say
unspecified) ...that's what was confusing.

You're right about the <functionalrelational templates. I'd forgotten
that. It's one of the places where less() is something more than a pure
wrapper around the < operator.

[Old Wolf]

Jack Klein wrote:

Frederick Gotham wroteL

>> SomeType const obj[2];
ptrdiff_t const diff = (char*)(obj + 1) - (char*)obj;

Subtracting pointers that do not point to parts of the same object is
undefined behavior.

But they do point to parts of the same object: the array 'obj'.