Is comparing two pointers with < undefined behavior if they are both cast to an integer type?

Question

Let's say I have this code that copies one block of memory to another in a certain order based on their location:

void *my_memmove(void *dest, const void *src, size_t len)
{
    const unsigned char *s = (const unsigned char *)src;
    unsigned char *d = (unsigned char *)dest;

    if(dest < src)
    {
        /* copy s to d forwards */
    }
    else
    {
        /* copy s to d backwards */
    }

    return dest;
}

This is undefined behavior if src and dest do not point to members of the same array^(6.8.5p5).

However, let's say I cast these two pointers to uintptr_t types:

#include <stdint.h>

void *my_memmove(void *dest, const void *src, size_t len)
{
    const unsigned char *s = (const unsigned char *)src;
    unsigned char *d = (unsigned char *)dest;

    if((uintptr_t)dest < (uintptr_t)src)
    {
        /* copy s to d forwards */
    }
    else
    {
        /* copy s to d backwards */
    }

    return dest;
}

Is this still undefined behavior if they're not members of the same array? If it is, what are some ways that I could compare these two locations in memory legally?

_{I've seen this question, but it only deals with equality, not the other comparison operators (<, >, etc).}

Answer 1

The conversion is legal but there is, technically, no meaning defined for the result. If instead you convert the pointer to void * and then convert to uintptr_t, there is slight meaning defined: Performing the reverse operations will reproduce the original pointer (or something equivalent).

It particular, you cannot rely on the fact that one integer is less than another to mean it is earlier in memory or has a lower address.

The specification for uintptr_t (C 2018 7.20.1.4 1) says it has the property that any valid void * can be converted to uintptr_t, then converted back to void *, and the result will compare equal to the original pointer.

However, when you convert an unsigned char * to uintptr_t, you are not converting a void * to uintptr_t. So 7.20.1.4 does not apply. All we have is the general definition of pointer conversions in 6.3.2.3, in which paragraphs 5 and 6 say:

An integer may be converted to any pointer type. Except as previously specified [involving zero for null pointers], 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.

Any pointer type may be converted to an integer type. Except as previously specified [null pointers again], the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.

So these paragraphs are no help except they tell you that the implementation documentation should tell you whether the conversions are useful. Undoubtedly they are in most C implementations.

In your example, you actually start with a void * from a parameter and convert it to unsigned char * and then to uintptr_t. So the remedy there is simple: Convert to uintptr_t directly from the void *.

For situations where we have some other pointer type, not void *, then 6.3.2.3 1 is useful:

A pointer to void may be converted to or from a pointer to any object type. A pointer to any object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.

So, converting to and from void * is defined to preserve the original pointer, so we can combine it with a conversion from void * to uintptr_t:

(uintptr_t) (void *) A < (uintptr_t) (void *) B

Since (void *) A must be able to produce the original A upon conversion back, and (uintptr_t) (void *) A must be able to produce its (void *) A, then (uintptr_t) (void *) A and (uintptr_t) (void *) B must be different if A and B are different.

And that is all we can say from the C standard about the comparison. Converting from pointers to integers might produce the address bits out of order or some other oddities. For example, they might produce a 32-bit integer contain a 16-bit segment address and a 16-bit offset. Some of those integers might have higher values for lower addresses while others have lower values for lower addresses. Worse, the same address might have two representations, so the comparison might indicate “less than” even though A and B refer to the same object.

Answer 2

No. Each results in an implementation-defined value, and comparison of integers is always well-defined (as long as their values are not indeterminate). Since the values are implementation-defined, the result of the comparison need not be particularly meaningful in regard to the pointers; however, it must be consistent with the properties of integers and the values that the implementation-defined conversions produced. Moreover, the C standard expresses an intent that conversions of pointers to integers should respect the address model of the implementation, making them somewhat meaningful if this is followed. See footnote 67 under 6.3.2.3 Pointers:

The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment.

However, some current compilers wrongly treat this as undefined behavior, at least under certain conditions, and there is a movement from compiler folks to sloppily formalize that choice via a notion of "provenance", which is gratuitously internally inconsistent and a disaster in the making (it could be made internally consistent and mostly non-problematic with trivial changes that are cost-free to code where it matters, but the people who believe in this stuff are fighting that for Reasons(TM)).

I'm not up-to-date on the latest developments in the matter, but you can search for "pointer provenance" and find the draft documents.

Answer 3

Comparing two pointers converted to uintptr_t should not have undefined behaviour at all. It does not even should have unspecified behaviour. Note that you should first cast the values to void * to ensure the same presentation, before casting to uintptr_t. However, compilers have had behaviour where two pointers were deemed to be unequal even though they pointed to the same address, and likewise, these pointers cast to uintptr_t compared unequal to each other (GCC 4.7.1 - 4.8.0). The latter is however not allowed by the standard. However there is *ongoing debate on the extent of pointer provenance tracking and this is part of it.

The intent of the standard according to C11 footnote 67 is that this is "to be consistent with the addressing structure of the execution environment". The conversion from pointer to integer is implementation-defined and you must check the implementation for the meaning of the cast. For example for GCC, it is defined as follows:

The result of converting a pointer to an integer or vice versa (C90 6.3.4, C99 and C11 6.3.2.3).

• A cast from pointer to integer discards most-significant bits if the pointer representation is larger than the integer type, sign-extends 2) if the pointer representation is smaller than the integer type, otherwise the bits are unchanged.

• A cast from integer to pointer discards most-significant bits if the pointer representation is smaller than the integer type, extends according to the signedness of the integer type if the pointer representation is larger than the integer type, otherwise the bits are unchanged.

• When casting from pointer to integer and back again, the resulting pointer must reference the same object as the original pointer, otherwise the behavior is undefined. That is, one may not use integer arithmetic to avoid the undefined behavior of pointer arithmetic as proscribed in C99 and C11 6.5.6/8.

For example on x86-32, x86-64 and GCC we can be assured that the behaviour of a pointer converted to uintptr_t is that the linear offset is converted as-is.

---

The last clause refers to pointer provenance, i.e. the compiler can track the identity of pointer stored in an (u)intptr_t, just like it can track the identity of a pointer in any other variable. This is totally allowed by C standard as it states just that you are ever guaranteed to be able to cast a pointer to void to (u)intptr_t and back again.

I.e.

 char foo[4] = "abc";
 char bar[4] = "def";

 if (foo + 4 == bar) {
     printf("%c\n", foo[4]); // undefined behaviour
 }

and given that foo + 4 compares equal to bar (allowed by the C standard), you cannot dereference foo[4] because it does not alias bar[0]. Likewise even if foo + 4 == bar you cannot do

 uintptr_t foo_as_int = (uintptr_t)(void *)foo;
 if (foo_as_int + 4 == (uintptrt_t)(void *)bar) {
     char *bar_alias = (void *)(foo_as_int + 4);

     printf("%c\n", bar_alias[0]); // undefined behaviour
 }

Answer 4

There is no guarantee that the numeric value produced by converting a pointer to uintptr_t have any meaningful relationship to the pointer in question. A conforming implementation with enough storage could make the first pointer-to-integer conversion yield 1, the second one 2, etc. if it kept a list of all the pointers that were converted.

Practical implementations, of course, almost always perform pointer-to-uintptr_t conversions in representation-preserving fashion, but because the authors of the Standard didn't think it necessary to officially recognize a category of programs that would be portable among commonplace implementations for commonplace platforms, some people regard any such code as "non-portable" and "broken". This completely contradicts the intention of the Standard's authors, who made it clear that they did not wish to demean programs that were merely conforming but not strictly conforming, but it is unfortunately the prevailing attitude among some compiler maintainers who don't need to satisfy customers in order to get paid.

Answer 5

No, it's only implementation-defined behavior. However, if you use == to make sure the objects overlap before comparing them with < or >, then it is neither implementation-defined behavior or undefined behavior. This is how you would implement such a solution:

#include <string.h>

void *my_memmove(void *dest, const void *src, size_t len)
{
    const unsigned char *s = src;
    unsigned char *d = dest;
    size_t l;

    if(dest == src)
        goto end;

    /* Check for overlap */
    for( l = 0; l < len; l++ )
    {
        if( s + l == d || s + l == d + len - 1 )
        {
            /* The two objects overlap, so we're allowed to
               use comparison operators. */
            if(s > d)
            {
                /* copy forwards */
                break;
            }
            else /* (s < d) */
            {
                /* copy backwards */
                s += len;
                d += len;
                while(len--)
                {
                    *--d = *--s;
                }
                goto end;
            }
        }
    }

    /* They don't overlap or the source is after
       the destination, so copy forwards */
    while(len--)
    {
        *s++ = *d++;
    }

end:
    return dest;
}