Pointers in C

"Raman" <ra***********@gmail.comwrites:

On Feb 21, 11:18 am, Ian Collins <ian-n...@hotmail.comwrote:
>Praveen wrote:
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.

>>>>Because that's what your compiler gives as the answer, subtracting two
>unrelated pointers is undefined behaviour.

Can Some onr tell why these are unrelated?

Because they point to distinct objects.

Here's what the standard says in the section on relational operators
(<, <=, >, >=) (C99 6.5.8p5):

When two pointers are compared, the result depends on the relative
locations in the address space of the objects pointed to. If two
pointers to object or incomplete types both point to the same
object, or both point one past the last element of the same array
object, they compare equal. If the objects pointed to are members
of the same aggregate object, pointers to structure members
declared later compare greater than pointers to members declared
earlier in the structure, and pointers to array elements with
larger subscript values compare greater than pointers to elements
of the same array with lower subscript values. All pointers to
members of the same union object compare equal. If the expression
P points to an element of an array object and the expression Q
points to the last element of the same array object, the pointer
expression Q+1 compares greater than P. In all other cases, the
behavior is undefined.

(A non-array object is treated as an array of one element.)

--
Keith Thompson (The_Other_Keith) 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.

Feb 21 '07 #6

Praveen said:

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.

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>

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

Feb 21 '07 #7

rafalp

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?
In pointer arithmetic the distance between two pointers is measured in
number of object of pointer's type that would fit between the memory
locations pointed by the pointers. 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.

Hope that helps.

Feb 21 '07 #8

rafalp said:

<snip>

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.

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

Feb 21 '07 #9

rafalp

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.

Feb 21 '07 #10

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.

Feb 21 '07 #11

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

>>>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Feb 21 '07 #12

Richard Tobin said:

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

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

Feb 21 '07 #13

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.

Feb 21 '07 #14

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

Feb 21 '07 #15

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

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Feb 21 '07 #16

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

Feb 21 '07 #17

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.

Feb 21 '07 #18

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?

Feb 21 '07 #19

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.

Feb 21 '07 #20

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

Feb 21 '07 #21

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.

Feb 21 '07 #22

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.

Feb 21 '07 #23

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

Feb 21 '07 #24

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.

Feb 21 '07 #25

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.

Feb 21 '07 #26

Flash Gordon

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

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

>>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.com
Last login: Wed 21 Feb 18:23:26 2007 on /dev/pts/4 from
staff-vpn21.staff-vpn.causeway.com
************************************************** *****************************
*
*
*
*
* 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

Feb 21 '07 #27

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

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

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

Feb 21 '07 #28

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

>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

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

Feb 21 '07 #29

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Feb 21 '07 #30

Richard Heathfield <rj*@see.sig.invalidwrites:

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

Feb 21 '07 #31

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

Feb 22 '07 #32

user923005

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

In article <EomdneUB5ItI30HYnZ2dnUVZ8tPin...@bt.com>,
Richard Heathfield <r...@see.sig.invalidwrote:

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

Feb 22 '07 #33

pete <pf*****@mindspring.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_Keith) 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.

Feb 22 '07 #34

pete

Keith Thompson wrote:

>
pete <pf*****@mindspring.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

Feb 22 '07 #35

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>

Feb 22 '07 #36

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.

Feb 22 '07 #37

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>

Feb 22 '07 #38

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.

Feb 22 '07 #39

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.

Feb 22 '07 #40

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

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

Feb 22 '07 #41

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.

Feb 22 '07 #42

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.

Feb 22 '07 #43

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

Feb 22 '07 #44

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

Feb 22 '07 #45