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.

[rafalp]

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

[santosh]

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

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.

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.

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.

Except for members of an union, objects cannot overlap in memory.

[santosh]

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.

[Clark S. Cox III]

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

Still not quite there. *Any* value or *no value at all* is a correct
result of subtracting those two pointers.

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

[Richard Heathfield]

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.

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

[Richard Heathfield]

rafalp said:

<snip>

But again, the question was not "what value should I get" but "why I
get 1 instead of some other value".

The only reasonable answer from a standard C perspective is "because, on
this occasion, that's the value you got".

When you break the rules of C, the compiler is released from any
obligation to be predictable.

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

[Flash Gordon]

Richard Tobin wrote, On 21/02/07 14:22:

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.

Even given that they are adjacent and the implementation happens to
produce something that looks sensible there is no guarantee that the
answer will be positive. For example:

markg@brenda:~$ cat t.c
#include <stdio.h>

int main(void)
{
int x, y ;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", (int)(p1-p2));
return 0;
}
markg@brenda:~$ gcc -ansi -pedantic -Wall -W -O t.c
markg@brenda:~$ ./a.out
1
markg@brenda:~$ ssh hal02
markg@hal02's password:
Last unsuccessful login: Mon 19 Feb 00:06:42 2007 on ssh from
staff-vpn20.staff-vpn.causeway.co m
Last login: Wed 21 Feb 18:23:26 2007 on /dev/pts/4 from
staff-vpn21.staff-vpn.causeway.co m
*************** *************** *************** *************** *************** ****
*
*
*
*
* Welcome to AIX Version 5.3!
*
*
*
*
*
* Please see the README file in /usr/lpp/bos for information pertinent
to *
* this release of the AIX Operating System.
*
*
*
*
*
*************** *************** *************** *************** *************** ****
markg@hal02 ~ $ cat t.c
#include <stdio.h>

int main(void)
{
int x, y ;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", (int)(p1-p2));
return 0;
}
markg@hal02 ~ $ gcc -ansi -pedantic -Wall -W -O t.c
markg@hal02 ~ $ ./a.out
-1
markg@hal02 ~ $

So we have the program (with the undefined behaviour fixed) giving 1 on
one system and -1 on another with both using gcc!

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.

That, indeed, is bad. However, you should probably specify which unix,
since not all versions are the same ;-)
--
Flash Gordon

[Keith Thompson]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

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.

[...]

The assumptions you listed are not sufficient to guarantee that the
objects are adjacent. It's likely that they are, but even then
there's no reason to assume that the result of the pointer subtraction
will be positive rather than negative.

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

[Richard Tobin]

In article <an************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwro te:

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

>Even given that they are adjacent and the implementation happens to
produce something that looks sensible there is no guarantee that the
answer will be positive.

We know that, without the casts to char *, the answer is 1. So if the
layout remains the same (as is likely), the answer with casts will be
sizeof(int) rather than -sizeof(int).

Though there are other loopholes. On a machine with no alignment
constraints, it's conceivable that the spacing is not a multiple of
sizeof(int), so it might be some value between sizeof(int) and twice
that.

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

That, indeed, is bad. However, you should probably specify which unix,
since not all versions are the same ;-)

I don't recall which version I found it in, probably BSD, around 1990.

I've just looked at the seventh edition code at
http://minnie.tuhs.org/UnixTree/V7/u...n/crypt.c.html
and it's in there:

/*
* The current block, divided into 2 halves.
*/
static char L[32], R[32];
[...]
encrypt(block, edflag)
char *block;
{
int i, ii;
register t, j, k;

/*
* First, permute the bits in the input
*/
for (j=0; j<64; j++)
L[j] = block[IP[j]-1];

So it was probably in many versions of unix for at least a decade.

-- Richard

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

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

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

>The assumptions you listed are not sufficient to guarantee that the
objects are adjacent. It's likely that they are, but even then
there's no reason to assume that the result of the pointer subtraction
will be positive rather than negative.

We know from the original post that the result is 1 without the casts
to char *. So unless sizeof(char *) is negative (an interesting idea)
the difference after casting will also be positive.

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