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.

[Richard Heathfield]

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

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

[Richard Tobin]

In article <Eo************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

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

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Richard Tobin said:

In article <Eo************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

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

The C Standard doesn't guarantee this, and no implementation is under
any obligation to provide that behaviour (even setting aside the fact
that there's no prototype in scope for printf and thus the behaviour is
undefined for another reason). Nothing in the rules says that x and y
have to be placed adjacently to each other in memory.

And yet I would like to provide a data point, of no relevance to the
guarantees provided by the Standard, and based purely on empirical
observation on one particular platform (a C8S16ILP32 system with a flat
address space), which seems to echo your point in a very strange way
indeed:

$ cat foo.c
#include <stdio.h>
int main(void)
{
int x;
int y = 1;
int z;
char *p = (char *)&x;
char *q = (char *)&z;
printf("%d\n", (int)(p - q) * y);
return 0;
}
$ ./foo
4

The incursion of y between x and z makes no difference, on this system.

And even if I get y's value at runtime, making it impossible to optimise
it away:

#include <stdio.h>

int main(void)
{
int x;
int y;
int z;
char *p = (char *)&x;
char *q = (char *)&z;
if(scanf("%d", &y) == 1)
{
printf("%d\n", (int)(p - q) * y);
}
return 0;
}

and provide 1 as an input, I *still* get an output of 4. Obviously the
program's behaviour is undefined, but common-sense observation suggests
that the compiler is placing x and z contiguously in memory even though
they are not defined adjacently. Incidentally, swapping y and z around
in the declaration order makes no difference. My compiler is determined
to keep x and z together, come what may. They were made for each other.

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

[santosh]

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);

you will get 4, ie sizeof(int), instead of 1. Is that what you expected?

The only thing you and the OP should expect is undefined behaviour.
You're both having the assumption that x and y are placed adjacently
in memory: something that's not required by the C standard.

<snip>

Thus with array

int a[10]

you can access the second element by a[1] or by *(a + 1). We add 1 to
the actual pointer but in fact compiler adds 4 or sizeof(int) to the
pointer.

The Standard does not nail down the size of an int at four bytes. It
must be atleast >= sizeof(char) and 16 bits. For example under DOS
sizeof(int) is likely to be two.

Hope that helps.

Hope your post doesn't confuse the OP.

[Clark S. Cox III]

rafalp wrote:

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.

Still not true. For instance, you have no guarantee that p2 p1, or
that subtracting them will actually yield *any* value much less any
*particular* value. The behavior is completely undefined.
--
Clark S. Cox III
cl*******@gmail .com

[Richard Tobin]

In article <Po************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

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

>The C Standard doesn't guarantee this, and no implementation is under
any obligation to provide that behaviour (even setting aside the fact
that there's no prototype in scope for printf and thus the behaviour is
undefined for another reason). Nothing in the rules says that x and y
have to be placed adjacently to each other in memory.

Quite so, but we know that they are adjacent on the OP's system (given
the assumptions I listed). Of course, it's possible that adding the
casts to char * may change that, but I doubt it.

For years, the unix crypt program relied on two arrays being contiguous.
A case of unwarranted chumminess with the compiler, which worked until
someone used a different compiler.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[santosh]

santosh wrote:

rafalp wrote:

<snip>

Thus with array

int a[10]

you can access the second element by a[1] or by *(a + 1). We add 1 to
the actual pointer but in fact compiler adds 4 or sizeof(int) to the
pointer.

The Standard does not nail down the size of an int at four bytes. It
must be atleast >= sizeof(char) and 16 bits. For example under DOS
sizeof(int) is likely to be two.

Correction. sizeof(int) must be atleast >= sizeof(short).

[Richard Heathfield]

santosh said:

santosh wrote:

>rafalp wrote:

<snip>

Thus with array

int a[10]

you can access the second element by a[1] or by *(a + 1). We add 1
to the actual pointer but in fact compiler adds 4 or sizeof(int) to
the pointer.

The Standard does not nail down the size of an int at four bytes. It
must be atleast >= sizeof(char) and 16 bits. For example under DOS
sizeof(int) is likely to be two.

Correction. sizeof(int) must be atleast >= sizeof(short).

Not quite. It is true that the range of values of int must equal or
exceed the range of values of short, but the Standard does not forbid
the presence of padding bits in short, such that sizeof(short) >
sizeof(int). Weird but true. (I doubt very much whether any implementor
would be silly enough to do this, however.)

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

[santosh]

Richard Heathfield wrote:

santosh said:

santosh wrote:

rafalp wrote:

<snip>

Thus with array

int a[10]

you can access the second element by a[1] or by *(a + 1). We add 1
to the actual pointer but in fact compiler adds 4 or sizeof(int) to
the pointer.

The Standard does not nail down the size of an int at four bytes. It
must be atleast >= sizeof(char) and 16 bits. For example under DOS
sizeof(int) is likely to be two.

Correction. sizeof(int) must be atleast >= sizeof(short).

Not quite. It is true that the range of values of int must equal or
exceed the range of values of short, but the Standard does not forbid
the presence of padding bits in short, such that sizeof(short) >
sizeof(int). Weird but true. (I doubt very much whether any implementor
would be silly enough to do this, however.)

Thanks. Something slightly related: does CHAR_BIT include padding bits?

[rafalp]

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);

you will get 4, ie sizeof(int), instead of 1. Is that what you expected?

The only thing you and the OP should expect is undefined behaviour.
You're both having the assumption that x and y are placed adjacently
in memory: something that's not required by the C standard.

We should expect that pointer difference between two distinct objects of
the same type is greater or equal than size of that object type. And
that is what the question was about. The question, put it in other
words, might be: "the program outputs 1 and sizeof(int) == 4 (in this
case), so does it mean that x and y overlap in memory?". I think that it
is common among beginners to assume that pointer arithmetic works just
like int arithmetic.