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.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

Praveen said:

>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.

Even if the pointer arithmetic were legal (which others have already
pointed out, so I won't belabour it here), the call to printf is not.
Whether the (undefined) result of your illegal pointer arithmetic is
reported correctly by printf is undefined, because you failed to
provide a valid function prototype within the current scope at the
point of call to a variable argument function.

Headers are not decorative. They matter. In future, if you call printf,
do this:

#include <stdio.h>

Even with the #include, the behavior is undefined (a) because of the
invalid pointer subtraction, and (b) because printf with "%d" expects
an argument of type int, and pointer subtraction yields a value of
type ptrdiff_t.

Here's a more nearly portable version of the above program:

#include <stdio.h>
int main(void)
{
struct {
int x;
int y;
} s;
int *p1 = &s.x;
int *p2 = &s.y;
printf("%ld\n", (long)(p1-p2));
return 0;
}

The output on my system is "-1".

But even this program invokes undefined behavior, since pointer
subtraction is defined only for pointers to elements of the same array
(or just past the end of the array, with a single object treated as a
one-element array). For the above program, the compiler could
conceivably insert a padding byte between x and y, making the
subtraction meaningless.

Note that any object can be treated as an array of characters, so my
version of the program can be "fixed" by using char* rather than int*
(with appropriate conversions).

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

#include <stdio.h>
int main(void)
{
struct {
int x;
int y;
} s;
int *p1 = &s.x;
int *p2 = &s.y;
printf("%ld\n", (long)(p1-p2));
return 0;
}

The output on my system is "-1".

But even this program invokes undefined behavior, since pointer
subtraction is defined only for pointers to elements of the same array
(or just past the end of the array, with a single object treated as a
one-element array). For the above program, the compiler could
conceivably insert a padding byte between x and y, making the
subtraction meaningless.

The compiler could conceivably insert a padding byte
between x and y, only if sizeof(int) equals one.
x and y each have to have a valid address for type int.

--
pete

[user923005]

On Feb 21, 5:13 am, rich...@cogsci. ed.ac.uk (Richard Tobin) wrote:

In article <EomdneUB5ItI30 HYnZ2dnUVZ8tPin [e-mail]>,
Richard Heathfield <[e-mail].i nvalidwrote:

>>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".

If the system the OP is using has a flat address space, and uses those
addresses for C pointers, and performs subtraction of pointers to
distinct objects as if they were in the same object, then he will get
sizeof(int).

That assumes that the objects are allocated or subtracted from
automatic memory consecutively.
I don't think that there is any requirement for that to happen.

[Keith Thompson]

pete <pf*****@mindsp ring.comwrites:

Keith Thompson wrote:

>#include <stdio.h>
int main(void)
{
struct {
int x;
int y;
} s;
int *p1 = &s.x;
int *p2 = &s.y;
printf("%ld\n", (long)(p1-p2));
return 0;
}

The output on my system is "-1".

But even this program invokes undefined behavior, since pointer
subtraction is defined only for pointers to elements of the same array
(or just past the end of the array, with a single object treated as a
one-element array). For the above program, the compiler could
conceivably insert a padding byte between x and y, making the
subtraction meaningless.

The compiler could conceivably insert a padding byte
between x and y, only if sizeof(int) equals one.
x and y each have to have a valid address for type int.

You're assuming that an N-byte int has to be aligned on an N-byte
boundary. That's not necessarily the case. Suppose sizeof(int)==4,
and the struct layout is:

x at offset 0, 4 bytes
padding at offset 4, 1 bytes
y at offset 5 4 bytes

There's probably no good reason for a compiler to do this, but nothing
in the standard forbids it.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

>
pete <pf*****@mindsp ring.comwrites:

Keith Thompson wrote:

#include <stdio.h>
int main(void)
{
struct {
int x;
int y;
} s;
int *p1 = &s.x;
int *p2 = &s.y;
printf("%ld\n", (long)(p1-p2));
return 0;
}

The output on my system is "-1".

But even this program invokes undefined behavior, since pointer
subtraction is defined only for pointers
to elements of the same array
(or just past the end of the array,
with a single object treated as a
one-element array). For the above program, the compiler could
conceivably insert a padding byte between x and y, making the
subtraction meaningless.

The compiler could conceivably insert a padding byte
between x and y, only if sizeof(int) equals one.
x and y each have to have a valid address for type int.

You're assuming that an N-byte int has to be aligned on an N-byte
boundary.

Yes, I was.

That's not necessarily the case.

I forgot about that.

--
pete

[CBFalconer]

Richard Heathfield wrote:

santosh said:

<snip>

>does CHAR_BIT include padding bits?

Since unsigned char may not contain padding bits (see 6.2.6.2),
the answer is no.

Minor practical exception - a system with parity memory bits may
actually use CHAR_BIT+1 storage bits. However, those extra bits
are never visible to the programmer. Similarly for ECC memory.
Yet evil values can bring the system to a screeching halt.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>santosh said:

<snip>

>>does CHAR_BIT include padding bits?

Since unsigned char may not contain padding bits (see 6.2.6.2),
the answer is no.

Minor practical exception - a system with parity memory bits may
actually use CHAR_BIT+1 storage bits.

It is required to behave "as if" each byte has CHAR_BIT bits.

However, those extra bits
are never visible to the programmer.

In which case it's "as if" they don't exist. So my answer stands.

Similarly for ECC memory.
Yet evil values can bring the system to a screeching halt.

One of the jobs of a C programmer is to ensure that evil values never
happen.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Richard Heathfield wrote:

>>santosh said:

<snip>

does CHAR_BIT include padding bits?

Since unsigned char may not contain padding bits (see 6.2.6.2),
the answer is no.

Minor practical exception - a system with parity memory bits may
actually use CHAR_BIT+1 storage bits.

It is required to behave "as if" each byte has CHAR_BIT bits.

>However, those extra bits are never visible to the programmer.

In which case it's "as if" they don't exist. So my answer stands.

>Similarly for ECC memory.
Yet evil values can bring the system to a screeching halt.

One of the jobs of a C programmer is to ensure that evil values
never happen.

In the posited case such action is out of the reach of the
programmer. The system is protecting against hardware faults. Yet
the extra bits exist, and can often be seen via adroit manipulation
of your handy 'scope or data analyzer.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[rafalp]

santosh wrote:

rafalp wrote:

>santosh wrote:

>>rafalp wrote:
Praveen wrote:
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.
>
Well, if you change the last line to

printf("%d\n", (char*)p1-(char*)p2);

We should expect that pointer difference between two distinct objects of
the same type is greater or equal than size of that object type.

This is exactly what you should *not* expect. If these objects are
part of an array, then the pointer difference, (in terms of
magnitude), between any two objects of this array will be a multiple
of the size of a single object. But this only holds for objects that
are a part of an array, including those returned by malloc and co.
This is not the case in the example presented by the OP.

Perhaps I haven't made myself clear enough. I agree with all what you
have written above. You have said more or less what I meant to say :).

The OP is a beginner and as a fresh in C he/she expects that the
subtraction of addresses of two objects yields the distance between them
measured in *bytes*. And that's why he/she is surprised at getting the
value "1" from the program. And he/she would be as much surprised if the
two object were the part of the same array.

[rafalp]

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
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.