Function pointer comparison

On the comparison of function pointers http://www.newty.de/fpt/fpt.html#compare:

Code:

---

if(pt2Function >0)

---

Are function pointers when compared with integer values guaranteed to be unsigned? Otheerwise, this would fail for instance in kernel code or where the code located above 2GB in a 32-bit system, right?

I'm personally not sure if pointers are signed or unsigned... Anyone know?

I would do if (pt2Function != 0) instead - as zero is probably the only value that is sane to use, besides the address of a function.

--
Mats

I believe the behaviour is undefined since pointer comparison with the relational operators is not defined for a comparison between a pointer to an object and a null pointer (constant). I would also just compare for equality (or inequality) with a null pointer constant.

Furthermore, the preceding text ("You can use the comparison-operators (==, !=) the same way as usual.") hints that the mistake is a typographical error.

FWIW, I know of one 64-bit architecture system that doesn't have this problem - IBM z/Architecture (mainframes).

The reason it doesn't have this problem is because executable code can only reside below the 2GB address range. You can put data all the way up to 16 exabytes, but code is still below the 2GB "bar".

Todd

Quote:

---

Originally Posted by matsp

Are function pointers when compared with integer values guaranteed to be unsigned? Otheerwise, this would fail for instance in kernel code or where the code located above 2GB in a 32-bit system, right?

---

You did mean 64-bit system, right? Because, I don't know how you would get code above 2GB on a 32-bit system.

And yet another thought...

On a 64-bit system, the pointers should be... drum roll please... 64 bits, not 32 bits, so the concept of signed vs unsigned shouldn't come into play.

(Or, am I just rambling because I didn't read the link posted that kicked off this topic?)

Quote:

---

Originally Posted by Dino

And yet another thought...

On a 64-bit system, the pointers should be... drum roll please... 64 bits, not 32 bits, so the concept of signed vs unsigned shouldn't come into play.

(Or, am I just rambling because I didn't read the link posted that kicked off this topic?)

---

Well, it does - but only when you reach the boundary between 7FFF FFFF FFFF FFFF and 8000 0000 0000 0000 - which is quite unlikely in the current hardware architectures [unless we have severely scattered memory layout - which of course is possible or even likely - but perhaps not that much scattered].

--
Mats

Quote:

---

64 bits, not 32 bits, so the concept of signed vs unsigned shouldn't come into play.

---

What the number of bits in the type does to do with the signed/unsigned?

Quote:

---

Originally Posted by vart

What the number of bits in the type does to do with the signed/unsigned?

---

An address of X'F0000000' on a 32 bit system could be evaluated as a signed integer, and it would be negative.

That same address on a 64-bit system would be X'00000000 F0000000', and if evaluated as a (long) integer, it would not be negative.

Right?

Quote:

---

Originally Posted by matsp

Well, it does - but only when you reach the boundary between 7FFF FFFF FFFF FFFF and 8000 0000 0000 0000 - which is quite unlikely in the current hardware architectures [unless we have severely scattered memory layout - which of course is possible or even likely - but perhaps not that much scattered].

--
Mats

---

You mean 7FFF FFFF FFFF FFFF and FFFF FFFF FFFF FFFF, right? Otherwise, you're talking about a single byte worth of addressing.

Quote:

---

Right?

---

Yes this particular address will be positive, while as Mats has shown, there are other adresses, that still could be interpreted as negative...

Quote:

---

Originally Posted by Dino

You mean 7FFF FFFF FFFF FFFF and FFFF FFFF FFFF FFFF, right? Otherwise, you're talking about a single byte worth of addressing.

---

When you go above 7 (15*F) a signed 64-bit integer turns negative, and does so for the 2^63 numbers up to FFFF FFFF FFFF FFFF, just like in 16-bits ANYTHING above 7FFF is negative [and much easier to write!] all the way to FFFF.

--
Mats

Correct, I understand. And I now understand that you meant FFFF FFFF FFFF FFFF and not 8000 0000 0000 0000.

Quote:

---

Originally Posted by Dino

Correct, I understand. And I now understand that you meant FFFF FFFF FFFF FFFF and not 8000 0000 0000 0000.

---

I'm guessing there's not quite understanding yet. We want two addresses that are right next to each other, so that we can have a boundary. 7FFF FFFF FFFF FFFF and 8000 0000 0000 0000 are addresses that are right next to each other, so there's a boundary between them. The first is (or can be) interpreted as positive, the second is (or can be) interpreted as negative, so it's a boundary that means something. 7FFF FFFF FFFF FFFF and FFFF FFFF FFFF FFFF are a very long way apart, and there can not be a boundary between them, since they are not adjacent.

Quote:

---

Originally Posted by Dino

Correct, I understand. And I now understand that you meant FFFF FFFF FFFF FFFF and not 8000 0000 0000 0000.

---

Actually, I meant 8 and lots of zeros - because I meant that you cross the boundary of 7(fill with F) and 8(Fill with 0) - The former is positive, the latter negative - and everything above [above in the unsigned world] that is obviously also negative, all the way to all F's.

--
Mats

Thanks guys. I really do understand all this. The terminology I (was) stuck on was "when you reach the boundary between...".

You can't "reach" the boundary between, because there is nothing (no address) between 7F's and 80's, so you can only cross over the boundary.

However after letting this sink in some more, this phrase is fine. I have typically used other phrases to denote the change in addressing limits.