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 Tobin]

In article <er**********@i news.gazeta.pl> , rafalp <{m**@gazeta.pl wrote:

>For other computers, comparing a pointer in one ring to
a pointer in another ring might cause a security violation error at the
hardware level (i.e., before the C implementation can even react to it),
terminating the program with extreme prejudice.

>No, because you're not accessing memory in "another ring". Comparing
pointers is not the same as accessing memory they point to.

It might be that merely comparing or subtracting two addresses in
different rings causes an exception, because there may be no ordering
defined between addresses in different rings. (By the way, C requires
comparing for equality to work.)

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

[Keith Thompson]

rafalp <{m**@gazeta.pl writes:

Richard Bos wrote:

[...]

>For other computers, comparing a pointer in one ring to
a pointer in another ring might cause a security violation error at the
hardware level (i.e., before the C implementation can even react to it),
terminating the program with extreme prejudice.

No, because you're not accessing memory in "another ring". Comparing
pointers is not the same as accessing memory they point to.

Comparing (using the relational operators <, <=, >, or >=) two
pointers that don't point to the same object invokes undefined
behavior. It's easy to assume that this will always yield some
sensible result, but the standard simply doesn't guarantee it.

If the standard required a flat linear address space, then the
relational operators could be required to yield consistent results;
for any two pointer of the same type, it could guarantee that exactly
one of x < y, x == y, x y is true, and define a total ordering. But
that would make it more difficult to implement C on hardware with more
exotic memory models. The current definition makes it possible to
implement C on hardware on which pointer comparisons don't necessarily
yield consistent results, or even where attempting such a comparison
might crash the program.

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

[Old Wolf]

On Feb 22, 7:30 am, Flash Gordon <[e-mail] te:

>
int main(void)
{
int x, y ;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", (int)(p1-p2));
return 0;}

So we have the program (with the undefined behaviour fixed)

For some definitions of 'fixed' !

[Old Wolf]

On Feb 22, 5:59 am, Richard Heathfield <[e-mail].i nvalidwrote:

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.

You could have CHAR_BIT be 12, and signed char have 8 value
bits and 4 padding bits (for example).

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.in validwrote in message

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.

The Nintendo 64 was one such computer.
There was a ninth bit which, if completely crazed, you could raid with
special assembly instructions
to squeeze some extra memory out of the system.

[CBFalconer]

rafalp wrote:

>

.... snip ...

>
Can you think of a real that checks relate-ness of pointers prior to
subtracting them and performs two different algorithms depending on
whether they are related or not?

It doesn't need to. The operation is undefined.

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

[Flash Gordon]

Old Wolf wrote, On 22/02/07 21:28:

On Feb 22, 7:30 am, Flash Gordon <[e-mail] te:

>int main(void)
{
int x, y ;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", (int)(p1-p2));
return 0;}

So we have the program (with the undefined behaviour fixed)

For some definitions of 'fixed' !

Quite right, lets say the undefined behaviour other than the specific
piece that the OP was interested in. I agree the pointer subtraction
still invoked undefined behaviour and I should have mentioned that.
--
Flash Gordon

[Richard Bos]

rafalp <{m**@gazeta.pl wrote:

Richard Bos wrote:

rafalp <{m**@gazeta.pl wrote:

Clark S. Cox III napisaÅ?(a):
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.
Can you think of a real that checks relate-ness of pointers prior to
subtracting them and performs two different algorithms depending on
whether they are related or not?

Who's talking about two different _algorithms_?

Actually santosh is. He said "not every compiler does that" in response
to my "compilers perform the same operations".

That doesn't mean that they don't follow the same algorithm. Even if
your compiled program follows the same algorithm, your OS or even your
memory controller could ensure that the result is different.

For other computers, comparing a pointer in one ring to
a pointer in another ring might cause a security violation error at the
hardware level (i.e., before the C implementation can even react to it),
terminating the program with extreme prejudice.

No, because you're not accessing memory in "another ring".

Accessing memory is irrelevant. Just comparing two pointers to different
security rings using < or could cause a trap. And the Standard allows
it to.

Richard

[Daniel Rudy]

At about the time of 2/21/2007 11:43 AM, Richard Tobin stated the following:

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

Not necessarily. Did you see Flash Gordon's post (Message ID:
<an************ @news.flash-gordon.me.uk>) when he ran it on a AIX 5.3
machine? It gave -1 as the answer. Two different platforms gives two
different answers, both compiled with gcc.

As most of us here know, undefined behavior is undefined behavior:
anything can happen, any result is possible. It all depends on your
implementation, compiler, and platform.
--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Daniel Rudy]

At about the time of 2/20/2007 10:11 PM, Praveen stated the following:

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.

It's undefined behavior for reasons that others have pointed out.

In this case, x and y are placed ajacent in memory, so the difference is
1 since you are subtracting int pointers. Some people here have had -1
on their systems.

strata:/home/dr2867/c/test 1062 $$$ ->cat ub001.c
#include <stdio.h>

int main(void)
{
int x;
int y;
int *p1 = &x;
int *p2 = &y;
printf("%d\n", p1 - p2);
printf("p1 = %0#x\np2 = %0#x\n", (unsigned int)p1, (unsigned int)p2);

return(0);
}

strata:/home/dr2867/c/test 1063 $$$ ->./compile ub001 ub001.c

Output File: ub001

Input Files:
ub001.c

gcc -W -Wall -Wshadow -Wpointer-arith -Wcast-align -Wstrict-prototypes
-Wnested-externs -Wwrite-strings -Wflo
at-equal -Winline -Wtrigraphs -ansi -std=c89 -pedantic -ggdb3 -o ub001
ub001.c

strata:/home/dr2867/c/test 1064 $$$ ->./ub001
1
p1 = 0xbfbfec34
p2 = 0xbfbfec30
strata:/home/dr2867/c/test 1065 $$$ ->
Look at the values of p1 and p2. They are 4 off, but it returns 1
because sizeof(int) is 4...at least on my system and apparently yours too.


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep