Programming

I think it's reasonably portable among 32-bit and 64-bit varieties of UNIX, and 32-bit varieties of Windows. Perhaps not 64-bit windows, in which long inexplicably doesn't change size even though the integer width of the processor doubles... The printf "%p" option is portable, but what it actually ends up printing is entirely platform and library-specific. Sometimes you get hex, sometimes you don't. Sometimes you get a leading 0x, sometimes you don't. On an old DOS compiler I got ????:???? for segment and offset -- making pointers portable on that was a whole new ball of wax, it had at least two different kinds!

so when i do the print (&a-&b) which gets me a 1, that means that the values were in the heap, and when i do the print(c-d), c and d were in the stack.
but why does values in the heap have a different arithmetic then the values in the stack?

Where the variable is stored has nothing to do with how it does pointer math. I can't see your code from here, but I'd venture they were all on the stack, with nothing in the heap. What type it's stored in does matter. Math on pointers is done in multiples of the base size, math on integers is just plain math.

So &a-&b is arithmetic on pointers themselves, and happens in multiples of the base size.

But if you convert them to integers first -- integers, not pointers to integers -- the compiler is no longer aware of any base size and does just plain arithmetic.

Try this:

Code:

#include <stdio.h>

int main(void)
{
        int a;
        int *b=&a;
        int *c=b+1;
        int d=b;
        int e=c;

        printf("diff between pointers is: %d\n", (unsigned long)(c-b));
        printf("diff between ints is: %d\n", e-d);
}

This makes it more obvious what's going on.

When you do math on a pointer, it puts it in terms of it's base size. An integer pointer plus one, actually gets sizeof(int) added to it, in this case 4. For plain integers, it makes no adjustment.

ok, can you explain more about
"When you do pointer arithmetic directly, the compiler does a little more legwork for you, delivering the result in multiples of the base size."

I think I did, and we crossposted. But to simplify a bit:

Code:

int a;
int n=&a;
n++; // n is an integer.  it adds only one.
int *o=&a;
o++; // o is a pointer.  it adds sizeof(int).

Pointer math happens relative to the base size. integer math is just plain math.

for chars if i do a="a" then get the address (&a) i get some large negative number, but i know the size of a char is 1 byte or 8 bits, so shouldn't the value be between 0 and 255 ?

also if converting an address of an int to hex and printing it why is it never negative?

The reason pointer arithmetic is scaled for the base type is simply to support array operations.

Given

int x[2];

... we access the second element of the array by writing x[1] or equivalently *(x + 1). You cannot fully separate arrays and pointers because the value of an array is a pointer to its first element, such that most array operations will involve pointers to their elements. It would be quite inconvenient and error-prone if we had to multiply the element number with the base type size to access the element.

The address of your char has a different type - it's char *, not char - and will probably (but not necessarily) have the same size as any other pointer, and typically amounts to 32 or 64 bits on most systems.

Signedness is a matter of how the data is interpreted. The %x format specifier expects an unsigned argument and will therefore treat all bits as data, whereas if you're using %d, the most significant bit of your value will be treated as sign bit - if it's set, the number is negative, otherwise it isn't.

Pointer encoding is system-specific, but it is generally not signed, so you should not print it as a signed value.

On Windows (and arguably other systems as well, though I tend to use unsigned long) it is best to convert your pointer to size_t, because that will give you an __int64.