4
int *x = 3;
int *y = 3;

if (x == y) "this statement evaluates to true" (pointer equality statement)
if (*x == *y) "this statement evaluates to true"

Is the reason that the pointer equality statement becomes true, just purely because COMPILER saw two "static" numbers "3" and said, hey point this to the same place? Or is there some magic for integers in general.

It obviously seems redundant that deferencing an integer pointer is the same (in this case) as not dereferencing.

I've seen some examples of this problem pertaining to strings (Addresses of two pointers are same), but wanted to clarify it more.

Community
  • 1
  • 1
kgaidis
  • 14,259
  • 4
  • 79
  • 93
  • what compiler and what options did you use – rerun Oct 11 '13 at 19:50
  • 8
    When you de-reference x, you're looking in memory address "3". You're very lucky you don't get a seg-fault at this point. – abelenky Oct 11 '13 at 19:51
  • "just purely because COMPILER saw two "static" numbers "3" and said, hey point this to the same place?" - no. No optimization needs to be done for this to behave as-is. Just common sense. –  Oct 11 '13 at 19:52
  • 8
    @abelenky Unlucky. – sepp2k Oct 11 '13 at 19:52
  • 2
    If you have coerced your operating system to map I/O ports, hardware registers, or even shared memory to address 3 of your memory space, consecutive reads of the mapped memory may not return the same value. But if you did this kind of mapping, you'd declare your pointers as `volatile` to prevent the compiler from optimizing away the read. – indiv Oct 11 '13 at 20:19

3 Answers3

10
int *x = 3;

This is invalid (a constraint violation), and a conforming compiler is required to issue a diagnostic, and may reject it altogether. You cannot use an integer value to initialize a pointer (except for the special case of 0, which is a null pointer constant).

If a compiler happens to accept it it will probably treat it as equivalent to:

int *x = (int*)3;

which causes the pointer x to point to address 3 in memory. This is almost certainly nonsensical.

Given that x and y are initialized with the same expression (and assuming your code isn't rejected), it's not at all surprising that x == y is true.

Dereferencing x has undefined behavior; (int*)3 is very probably not a valid address, because it's outside your program's legal addressing space and/or because it's misaligned. But if *x happens to "work" and yield a value, it's also not surprising that *x == *y is true. It's possible that the compiler recognized that x == y and therefore concluded that *x == *y. You might determine that by examining the generated code. But it really doesn't matter; once your program's behavior is undefined, quite literally anything can happen (or rather, the language standard permits literally anything to happen; the laws of physics might have something else to say about it).

You should have gotten a warning for both declarations. If you did, you should heed it. If you didn't, you should find out how to increase the warning levels for your compiler.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • thank you, I actually didn't get to test this myself, but rather was presented in my class and the logic kept bugging me. Usually when I'm confused about something, there always seems to be something wrong with it to begin with, so that seems to be the case again. I guess the point the teacher was trying to bring about is that there is a difference between pointer "variable" addresses (&x and &y), and the addresses that the pointer actually points to. I actually thought that the way he presented meant that the pointer gets the value "3." Annnnnd that's where I started doubting my knowledge – kgaidis Oct 11 '13 at 20:37
  • 2
    @anon: Right, the problem is that `3` isn't a pointer value. An example using, say, `(int*)0xdeadbeef`, while making it clear that that's just an example and not necessarily a valid address, might have gotten the point across more clearly. There's a common attitude that integer and pointers are "really" the same thing, but IMHO it's best to keep the concepts distinct. – Keith Thompson Oct 11 '13 at 21:06
6

You've simply hardcoded a fixed memory address for both pointers, 3. Stands to reason that this simple address is the same, and that whatever data is actually AT that address will also be the same.

It's like you've got two sticky notes on your fridge. Both says "keys are on table by door". And by jove, when you go look by the door, there's your keys. Two different pointers, both pointing at the same thing.

Marc B
  • 356,200
  • 43
  • 426
  • 500
  • 2
    You're assuming that `int *x = 3;` is equivalent to `int *x = (int*)3;`. It's not clear that that's true. In any case, it's a constraint violation. – Keith Thompson Oct 11 '13 at 19:56
2

Both of the declaration 

int *x = 3;
int *y = 3;

are constraint violation. You can declare 

int *x = (int *)3;
int *y = (int *)3;

these both are referring to the address 3 of memory. 

if (*x == *y) "this statement evaluates to true"

No. It invokes undefined behavior. You may get anything. Either this evaluates to true or false

haccks
  • 104,019
  • 25
  • 176
  • 264