CODEWITHSUNDEEP
cpointerslanguage-lawyer
Some Name
Some Name

Reputation: 9540

Are two pointers comparing equal converted to an integer type compare equal?

Question: If pointers comparing equals are their integer-converted values also equal?

For example:

void *ptr1 = //...
void *ptr2 = //...
printf("%d", ptr1 == ptr2); //prints 1

Does it mean that (intptr_t) ptr1 == (intptr_t) ptr2 is also 1?

From pragmatic point of view that should be right. But considering what the Standard specifies at 7.20.1.4(p1):

The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

    intptr_t

it does not contradict to that an implementation can convert the same pointers to different values (depending on some weird circumstances), preserving that the values converted back yields the same pointers.

So, I think no, the integer-converted values of pointers comparing equal are not necessary equal to each other.

Upvotes: 8

Views: 365

Answers (3)

Keith Thompson
Keith Thompson

Reputation: 263627

In almost all implementations, two pointers are equal if and only if their representations are equal, but the standard doesn't guarantee that.

The fact that ptr1 == ptr2 doesn't imply that ptr1 and ptr2 have the same representation. N1570 6.5.9 paragraph 6:

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.

For example, suppose a pointer is represented as a two-part entity, with the first part identifying a segment of memory, and the second part a byte offset within that segment. If two segments can overlap, then there can be two different pointer representations for the same memory address. The two pointers would compare as equal (and the generated code would likely have to do some extra work to make that happen), but if conversion to intptr_t just copies the representation then (intptr_t)ptr1 != (intptr_t)ptr2.

(It's also possible that the pointer-to-integer conversion could normalize the representation.)

This possibility is why == and != are well defined for pointers to different objects, but the relational operators (<, <=, >, >=) are undefined. The equality operators have to determine whether the two pointers point to the same location, but the relational operators are allowed to compare only the offsets and ignore the base portion (assuming that each object is in a single segment). In practice, almost all modern systems have a monolithic address space, and the equality and relational operators work consistently even though the standard doesn't require them to do so.

Upvotes: 7

supercat
supercat

Reputation: 81307

An implementation in which the size of a pointer is between that of two integer types (e.g. segmented-mode 80386, where pointers were 48 bits) might process something like:

uintptr_t my_uintptr = (uintptr_t)myptr;

by storing myptr into the first 48 bits of my_uintptr and leaving the remaining bits holding arbitrary values, provided that a later conversion myptr = (void*)my_uintptr; ignores the value of those bits.

Since there's no guarantee that repeated conversions of the same pointer to uintptr_t will yield the same value, there's likewise no guarantee in the case where the pointers being converted compare equal despite having been produced by different means.

If, however, an implementation documents the storage formats for pointers and integers, and documents how conversions are performed, and if there is no way that a behavior could behave in a fashion consistent with that documentation without upholding stronger semantic guarantees, then the implementation should be expected to uphold such guarantees. I don't think the Standard requires that implementations behave in a fashion consistent with their documentation as a condition of conformance, but the notion that quality implementations should be expected to behave as documented should be sufficiently self-evident that the Standard shouldn't need to require it.

Upvotes: 6

StoryTeller - Unslander Monica
StoryTeller - Unslander Monica

Reputation: 170240

Your analysis is correct. Other than allowing conversions to and from integers at §6.3.2.3, the standard doesn't mention how that conversion should behave. Granted, there is a "round trip" requirement on intptr_t, but it doesn't prevent more than a single trip being possible, with the compiler choosing one or another based on some constraint or requirement.

So indeed, the C standard doesn't require (intptr_t) ptr1 == (intptr_t) ptr2 to hold.

Upvotes: 8

Related Questions