pointer problem

[stevesmithx]

Hi all,
I have trouble understanding the following code.

#include <stdio.h>
int main(void){
	int *p,*q,i;
	p=(int *)100;
	q=(int *)700;
	i=q-p;
	printf("\n%d\n",i);
	return 0;
}

The output comes as
300
can somebody please explain this.
Any help would be appreciated.
-------
stevesmithx

[nadroj]

to me, it looks like your assigning to p and q an address to a location in memory of size 'int', rather than signing integer values '100' and '700' (in which case youd expect the output to be 600). when you do q-p, its subtracting the hexadecimal addresses corresponding to q and p, respectively. this difference happens to be 300 in base 10 (decimal).

[stevesmithx]

Thanks for replying, nadroj.
I traced the addresses assigned to p and q using debugger.
For p->0064(corresponds to 100 in decimal)
q->02BC(corresponds to 700 in decimal)
So the difference between the two should be 600(in decimal).
I am confused why 300 should come as output.
Can you explain that part,please.

[Elysia]

It actually makes sense, because pointers are not integers.
If you subtract from a pointer, you will subtract n - sizeof(*p).
So when you subtract 100 from the integer pointer, you actually subtract a total of 100 * sizeof(int), which is 400, and 700 - 400 = 300.
This is actually a good thing since we can increment pointers by doing n++, which would then point to the next element in an array or n-- which would do the reverse.

[laserlight]

My opinion is that the behaviour here is undefined, but my guess is that because pointer difference gives the number of elements between the two pointers, the result of 300 means that there are 300 ints between p and q. Since the difference in raw address values is 600, the implication is that sizeof(int) is 600/300=2 on your system.

So when you subtract 100 from the integer pointer, you actually subtract a total of 100 * sizeof(int), which is 400, and 700 - 400 = 300.

It is not subtracting 100 from the int*, but another int* from the int* to return a ptrdiff_t.

[Elysia]

It might also be worth noting that simply because one pointer is located at address 100 and one at 700, does not mean there are 600 integers between there [there would only be space for 600 / sizeof(int)].

[stevesmithx]

Now I can understand that.
Thank you very much to all of you.
One more question,
Is it right to assume the sizeof(int) always as 2?

[Elysia]

No, far from it.
On a x86/x64 machine running Windows, sizeof(int) = 4.
I believe, on Linux or some other platform (with x64), sizeof(int) = 8

[laserlight]

stevesmithx, just to confirm my reasoning, have you checked the value of sizeof(int) on your system by printing it?

[Elysia]

Oh and no type except char (sizeof(char) is always 1) is guaranteed to have the same size of all platforms.
They have different sizes on different platforms, which is actually where there exists a couple of typedefs that when used is guaranteed to be the size you look for.

[stevesmithx]

No, far from it.
On a x86/x64 machine running Windows, sizeof(int) = 4.
I believe, on Linux or some other platform (with x64), sizeof(int) = 8

Thank you Elysia,
I asked this question because this was asked as an interview question.
So now i am assured that none of their choices were correct.

stevesmithx, just to confirm my reasoning, have you checked the value of sizeof(int) on your system by printing it?

I checked it.You are right.It was 2.
Thank you all.

[shwetha_siddu]

My opinion is that the behaviour here is undefined, but my guess is that because pointer difference gives the number of elements between the two pointers, the result of 300 means that there are 300 ints between p and q. Since the difference in raw address values is 600, the implication is that sizeof(int) is 600/300=2 on your system.


It is not subtracting 100 from the int*, but another int* from the int* to return a ptrdiff_t.

Hai Dear
I am getting output of same program as 150 what may be the reason?
i am not able to follow this:-

[Elysia]

Well, if you follow laserlight's reasoning, then if sizeof(int) = 4, then you would get 150.

[matsp]

No, far from it.
On a x86/x64 machine running Windows, sizeof(int) = 4.
I believe, on Linux or some other platform (with x64), sizeof(int) = 8

Not correct, sizeof(int) is 4 on x86_64 as well as on 32-bit x86 (but long is 8 in x86_64). That's not to say that machines where sizeof(int) == 8 or sizeof(int) == 1 may exist. 4 is certainly the common value in modern compilers/OS's, but it's absolutely not guaranteed. The only provisions in the standard is that:

sizeof(char) == 1;
sizeof(short) >= sizeof(char)
sizeof(int) >= sizeof(short)
sizeof(long) >= sizoef(int)
sizeof(long long) >= sizeof(long)

Theoretically, it's valid to build a compiler where all those sizes are 1. It would just either make all integers pretty small (char = 8 bits) or strings take up quite a bit of space (char = 32/64 bits).

--
Mats

[robwhit]

While all data types could be the same size, there are minimum sizes in C89 -- 2.2.4.2, C99 -- 5.2.4.2.1, for integral types. So an int could not take up only 8 binary bits.