18

Inspired by this answer about dynamic cast to void*:

...
bool eqdc(B* b1, B *b2) {
    return dynamic_cast<void*>(b1) == dynamic_cast<void*>(b2);
}
...
int main() {
    DD *dd = new DD();
    D1 *d1 = dynamic_cast<D1*>(dd);
    D2 *d2 = dynamic_cast<D2*>(dd);
    ... eqdc(d1, d2) ...

I am wondering if it is fully defined behaviour in C++ (according to the 03 or 11 standard) to compare two void pointers for (in)equality that point to valid, but different objects.

More generally, but possibly not as relevant, is comparing (==or !=) two values of type void* always defined, or is it required that they hold a pointer to a valid object/memory area?

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337

2 Answers2

13

C says:

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space.

C++ says:

Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address.

Hence it would mean that:

a)

it is fully defined behaviour in C++ (according to the 03 or 11 standard) to compare two void pointers for (in)equality that point to valid, but different objects.

So yes, in both C and C++. You can compare them and in this case they shall compare as true iff they point to the same object. That's simple.

b)

is comparing (==or !=) two values of type void* always defined, or is it required that they hold a pointer to a valid object/memory area?

Again, the comparison is well-defined (standard says "if and only if" so every comparison of two pointers is well-defined). But then...

  • C++ talks in terms of "address", so I think this means that the standard requires this to work "as we'd expect",
  • C, however, requires both the pointers to be either null, or point to an object or function, or one element past an array object. This, if my reading skills aren't off, means that if on a given platform you have two pointers with the same value, but not pointing to a valid object (e.g. misaligned), comparing them shall be well-defined and yield false.

This is surprising!

Indeed that's not how GCC works:

int main() {
    void* a = (void*)1; // misaligned, can't point to a valid object
    void* b = a;
    printf((a == b) ? "equal" : "not equal");
    return 0;
}

result:

equal

Maybe it's UB in C to have a pointer which isn't a null pointer and doesn't point to an object, subobject or one past the last object in an array? Hm... This was my guess, but then we have that:

An integer may be converted to anypointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

So I can only interpret it that the above program is well-defined and the C standard expects it to print "not equal", while GCC doesn't really obey the standard but gives a more intuitive result.

Kos
  • 70,399
  • 25
  • 169
  • 233
  • 4
    "misaligned, can't point to a valid object" is false, since it *could* in theory point to a `char` object. Actually it doesn't point to an object, at least not on (say) linux in user mode, but I don't think we should read that quote from C as saying that the `==` operator for pointers should have to somehow detect whether the address is currently valid or not. Rather, I think it has gone without saying (in fact, has been said elsewhere) that valid programs don't use invalid addresses in the first place. – Steve Jessop Nov 22 '11 at 11:03
  • All've been cool if the standard would prohibit it to make invalid pointers... But looks like it doesn't (c99 6.3.2.3 p5). Well, we both understand what "should've been said" (and indeed has been said in C++), but it might be the case that C99 has failed to be strict enough here..? – Kos Nov 22 '11 at 11:09
  • What about if we want to compare with `operator<`? Is that defined behavior? – Ben Apr 27 '22 at 19:34
3

C++11, 5.10/1:

Pointers of the same type (after pointer conversions) can be compared for equality. Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address

So yes, the specific comparison is OK.

In general it is undefined behavior to attempt to create a pointer value that isn't a valid address - for example using pointer arithmetic to go before the beginning or after the one-after-the-end of an array - let alone use them. The result of stuff like (void*)23 is implementation-defined, so barring specific permission from the implementation it is in effect undefined behavior to compare those too, since the implementation might define that the result is a trap value of void*.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • 1
    Why does implementation-defined imply undefined here? – Kos Nov 22 '11 at 11:06
  • @Kos: well, the value is implementation-defined, which means that the implementation could define it to return a trap value (if the implementation has trap values of pointers), which would have undefined behavior when used. So unless you know what the implementation-defined behavior is when you write the code, or at least know that the implementation treats pointer values basically like integers that will never trap, then it's as bad as if it were UB. Most implementations are safe, but since the question is about what the standard guarantees... – Steve Jessop Nov 22 '11 at 11:38