Pointers in C

[Praveen]

Hi,

I came across a program as follows
main()
{
int x, y ;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", p1-p2);
}

The output of the above program is 1.
Can some one explain me how it is 1.
Thanks in advance.

[Clark S. Cox III]

rafalp wrote:

santosh wrote:

>rafalp wrote:

>>Richard Heathfield wrote:
rafalp said:
Richard Heathfield wrote:
>rafalp said:
>>
>>Well, if you change the last line to
>>>
>>printf("% d\n", (char*)p1-(char*)p2);
>>>
>>you will get 4, ie sizeof(int), instead of 1.
>No, the behaviour will still be undefined, for two separate reasons.
You're right. I should have written "you will get value >=
sizeof(int) " instead.
No, you should have written something like "the value you get, if any,
is not defined by the rules of C - to get a well-defined result, write
a well-defined program".

You are perfectly right here. I forgot about p1 < p2 case ;).
But again, the question was not "what value should I get" but "why I get
1 instead of some other value".

You still don't seem to understand. It doesn't matter what the values
of p1 and p2 are. In C, objects which are not part of an array are not
guaranteed to be physically adjacent in memory. In practise it might
commonly happen to be so, but that's only because of the choices the
implementati on makes and relying on it is dangerous.

So in the example presented by the OP, the value of p1-p2 could as
easily be 711935 instead of 1.

I'm not making anywhere the assumption that they are adjacent. My point
was to explain to the OP that for two given objects o1, o2 of the same type

&o1 - &o2 := (addressof(o1) - addressof(o2)) / sizeof(objects)

That's all.

Even that isn't guaranteed.

(&o1 - &o2) could be (42) and ((char*)&o1 - (char*)&o2) could be
('bananas'). Subtracting pointers to two objects that aren't part of
some other object (i.e. array, structure, union, etc.) is undefined.
--
Clark S. Cox III
cl*******@gmail .com

[santosh]

rafalp wrote:

santosh wrote:

<snip>

You still don't seem to understand. It doesn't matter what the values
of p1 and p2 are. In C, objects which are not part of an array are not
guaranteed to be physically adjacent in memory. In practise it might
commonly happen to be so, but that's only because of the choices the
implementation makes and relying on it is dangerous.

So in the example presented by the OP, the value of p1-p2 could as
easily be 711935 instead of 1.

I'm not making anywhere the assumption that they are adjacent. My point
was to explain to the OP that for two given objects o1, o2 of the same type

&o1 - &o2 := (addressof(o1) - addressof(o2)) / sizeof(objects)

That's all.

That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumption that the OP may not know about, are both wrong.

[rafalp]

santosh wrote:

>
That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumption that the OP may not know about, are both wrong.

OK. That's what C standard says.
I'm pretty sure that compilers perform the same operations when
subtracting any two pointers, no matter if they are related or not.
But still subtracting unrelated pointers is of little sense to me.

[rafalp]

Clark S. Cox III wrote:

>I'm not making anywhere the assumption that they are adjacent. My point
was to explain to the OP that for two given objects o1, o2 of the same type

&o1 - &o2 := (addressof(o1) - addressof(o2)) / sizeof(objects)

That's all.

Even that isn't guaranteed.

(&o1 - &o2) could be (42) and ((char*)&o1 - (char*)&o2) could be
('bananas'). Subtracting pointers to two objects that aren't part of
some other object (i.e. array, structure, union, etc.) is undefined.

I don't understand what you mean. (&o1 - &o2) and ((char*)&o1 -
(char*)&o2) give different results even if o1 and o2 are the part of the
same array unless sizeof(o1) == sizeof(char).

[Clark S. Cox III]

rafalp wrote:

santosh wrote:

>>
That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumption that the OP may not know about, are both wrong.

OK. That's what C standard says.
I'm pretty sure that compilers perform the same operations when
subtracting any two pointers, no matter if they are related or not.

*Your* compiler might do that but not every compiler does that. Think of
a segmented architecture with completely separate memory spaces.

But still subtracting unrelated pointers is of little sense to me.

Of course it makes little sense--the result is completely undefined.

--
Clark S. Cox III
cl*******@gmail .com

[Clark S. Cox III]

rafalp wrote:

Clark S. Cox III wrote:

>>I'm not making anywhere the assumption that they are adjacent. My point
was to explain to the OP that for two given objects o1, o2 of the
same type

&o1 - &o2 := (addressof(o1) - addressof(o2)) / sizeof(objects)

That's all.

Even that isn't guaranteed.

(&o1 - &o2) could be (42) and ((char*)&o1 - (char*)&o2) could be
('bananas'). Subtracting pointers to two objects that aren't part of
some other object (i.e. array, structure, union, etc.) is undefined.

I don't understand what you mean. (&o1 - &o2) and ((char*)&o1 -
(char*)&o2) give different results even if o1 and o2 are the part of the
same array unless sizeof(o1) == sizeof(char).

If they are *not* part of the same array, there are no restrictions on
what either subtraction could yield, nor is there any guarantee that the
two results are related in any way (hence the "42" and "'bananas'" ).
--
Clark S. Cox III
cl*******@gmail .com

[rafalp]

Clark S. Cox III napisał(a):

rafalp wrote:

>santosh wrote:

>>That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumption that the OP may not know about, are both wrong.

OK. That's what C standard says.
I'm pretty sure that compilers perform the same operations when
subtracting any two pointers, no matter if they are related or not.

*Your* compiler might do that but not every compiler does that. Think of
a segmented architecture with completely separate memory spaces.

Can you think of a real that checks relate-ness of pointers prior to
subtracting them and performs two different algorithms depending on
whether they are related or not?

[santosh]

rafalp wrote:

Clark S. Cox III napisał(a):

rafalp wrote:

santosh wrote:
That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumption that the OP may not know about, are both wrong.
OK. That's what C standard says.
I'm pretty sure that compilers perform the same operations when
subtracting any two pointers, no matter if they are related or not.

*Your* compiler might do that but not every compiler does that. Think of
a segmented architecture with completely separate memory spaces.

Can you think of a real that checks relate-ness of pointers prior to
subtracting them and performs two different algorithms depending on
whether they are related or not?

No. Pointer arithmetic is valid only for pointers to the same object
or objects within an array. For other cases, the behaviour is
undefined. Specific implementations will usually emit a diagnostic but
go ahead and perform the operation anyway. Whether the result makes
sense is upto the programmer. In flat memory models and for objects of
the same type and scope, it *might* make sense. Most programs don't
need such information anyway.

[Richard Bos]

rafalp <{m**@gazeta.pl wrote:

Clark S. Cox III napisał(a):

rafalp wrote:

santosh wrote:
That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumption that the OP may not know about, are both wrong.
OK. That's what C standard says.
I'm pretty sure that compilers perform the same operations when
subtracting any two pointers, no matter if they are related or not.

*Your* compiler might do that but not every compiler does that. Think of
a segmented architecture with completely separate memory spaces.

Can you think of a real that checks relate-ness of pointers prior to
subtracting them and performs two different algorithms depending on
whether they are related or not?

Who's talking about two different _algorithms_? For some computers
(e.g., under MS-DOS), subtracting a pointer in one segment from one in
another might use the same algorithm as subtracting two pointers from
the same segment, but exactly _because_ of this give "wrong", semi-
random results. For other computers, comparing a pointer in one ring to
a pointer in another ring might cause a security violation error at the
hardware level (i.e., before the C implementation can even react to it),
terminating the program with extreme prejudice.

Richard

[rafalp]

Richard Bos wrote:

rafalp <{m**@gazeta.pl wrote:

>Clark S. Cox III napisaÅ?(a):

>>rafalp wrote:
santosh wrote:
That holds true only for two given objects o1, o2 of the same type
*and part of an array*. Two arbitrary objects can be placed anywhere
in memory and hence the difference of their addresses , (which invokes
undefined behaviour), need not be any expected value at all. The two
objects in OP's post were two arbitrary objects, hence his expectation
of any sensible output as well as your explanation based on an
assumptio n that the OP may not know about, are both wrong.
OK. That's what C standard says.
I'm pretty sure that compilers perform the same operations when
subtractin g any two pointers, no matter if they are related or not.
*Your* compiler might do that but not every compiler does that. Think of
a segmented architecture with completely separate memory spaces.

Can you think of a real that checks relate-ness of pointers prior to
subtracting them and performs two different algorithms depending on
whether they are related or not?

Who's talking about two different _algorithms_?

Actually santosh is. He said "not every compiler does that" in response
to my "compilers perform the same operations". That's why I asked.

For some computers
(e.g., under MS-DOS), subtracting a pointer in one segment from one in
another might use the same algorithm as subtracting two pointers from
the same segment, but exactly _because_ of this give "wrong", semi-
random results.

With that I fully agree. I have *not* stated anywhere in the discussion
that subtracting unrelated pointer makes any sense nor I'm defending
that thesis.

For other computers, comparing a pointer in one ring to
a pointer in another ring might cause a security violation error at the
hardware level (i.e., before the C implementation can even react to it),
terminating the program with extreme prejudice.

No, because you're not accessing memory in "another ring". Comparing
pointers is not the same as accessing memory they point to.