Pointers in C

[rafalp]

rafalp said:


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]

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]

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]

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.

 

[Richard Heathfield]

santosh said:

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]

rafalp said:

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.

 

[Flash Gordon]

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

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.[/QUOTE]

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

 

[Keith Thompson]

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.[/QUOTE]
[...]

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.

 

[Richard Tobin]

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.

[/QUOTE]

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.

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/usr/src/libc/gen/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

 

[Keith Thompson]

Praveen said:

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

 

[Richard Tobin]

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.

[/QUOTE]

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

 

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

 

[user923005]

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).[/QUOTE]

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]

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.

 

[pete]

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.

 

[CBFalconer]

santosh said:



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.

 

[Richard Heathfield]

CBFalconer said:

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.

 

[CBFalconer]

CBFalconer said:

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


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


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.

 

[rafalp]

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]

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.