uintptr_t 上的指针运算

Question

I have to implement a "bandpass" filter. Let a and b denote two integers that induce a half-open interval [a, b) . If some argument x lies within this interval (ie, a <= x < b ), I return a pointer to a C string const char* high , otherwise I return a pointer const char* low . The vanilla implementation of this function looks like

const char* vanilla_bandpass(int a, int b, int x, const char* low,
    const char* high)
{
    const bool withinInterval { (a <= x) && (x < b) };
    return (withinInterval ? high : low);
}

which when compiled with -O3 -march=znver2 on Godbolt gives the following assembly code

vanilla_bandpass(int, int, int, char const*, char const*):
        mov     rax, r8
        cmp     edi, edx
        jg      .L4
        cmp     edx, esi
        jge     .L4
        ret
.L4:
        mov     rax, rcx
        ret

Now, I've looked into creating a version without a jump/branch, which looks like this

#include <cstdint>

const char* funky_bandpass(int a, int b, int x, const char* low,
    const char* high)
{
    const bool withinInterval { (a <= x) && (x < b) };
    const auto low_ptr = reinterpret_cast<uintptr_t>(low) * (!withinInterval);
    const auto high_ptr = reinterpret_cast<uintptr_t>(high) * withinInterval;

    const auto ptr_sum = low_ptr + high_ptr;
    const auto* result = reinterpret_cast<const char*>(ptr_sum);
    return result;
}

which just is ultimately just a "chord" between two pointers. Using the same options as before, this code compiles to

funky_bandpass(int, int, int, char const*, char const*):
        mov     r9d, esi
        cmp     edi, edx
        mov     esi, edx
        setle   dl
        cmp     esi, r9d
        setl    al
        and     edx, eax
        mov     eax, edx
        and     edx, 1
        xor     eax, 1
        imul    rdx, r8
        movzx   eax, al
        imul    rcx, rax
        lea     rax, [rcx+rdx]
        ret

While at first glance, this function has more instructions, careful benchmarking shows that it's 1.8x to 1.9x faster than the vanilla_bandpass implementation.

Is this use of uintptr_t valid and free of undefined behavior? I'm well aware that the language around uintptr_t is vague and ambiguous to say the least, and that anything that isn't explicitly specified in the standard (like arithmetic on uintptr_t ) is generally considered undefined behavior. On the other hand, in many cases, the standard explicitly calls out when something has undefined behavior, which it also doesn't do in this case. I'm aware that the "blending" that happens when adding together low_ptr and high_ptr touches on topics just as pointer provenance, which is a murky topic in and of itself.

Answer 1

Is this use of uintptr_t valid and free of undefined behavior?

Yes. Conversion from pointer to integer (of sufficient size such as uintptr_t ) is well defined, and integer arithmetic is well defined.

Another thing to be wary about is whether converting a modified uintptr_t back to a pointer gives back what you want. Only guarantee given by the standard is that pointer converted to integer converted back gives the same address. Luckily, this guarantee is sufficient for you, because you always use the exact value from a converted pointer.

If you were using something other than pointer to narrow character, I think you would need to use std::launder on the result of the conversion.

Answer 2

The Standard doesn't require that implementations process uintptr_t -to-pointer conversions in useful fashion even in cases where the uintptr_t values are produced from pointer-to-integer conversions. Given eg

extern int x[5],y[5];
int *px5 = x+5, *py0 = y;

the pointers px5 and py0 might compare equal, and regardless of whether they do or not, code may use px5[-1] to access x[4] , or py0[0] to access y[0] , but may not access px5[0] nor py0[-1] . If the pointers happen to be equal, and code attempts to access ((int*)(uintptr_t)px5)[-1] , a compiler could replace (int*)(uintptr_t)px5) with py0 , since that pointer would compare equal to px5 , but then jump the rails when attempting to access py0[-1] . Likewise if code tries to access ((int*)(uintptr_t)py0)[0] , a compiler could replace (int*)(uintptr_t)py0 with px5 , and then jump the rails when attempting to access px5[0] .

While it may seem obtuse for a compiler to do such a thing, clang gets even crazier. Consider:

#include <stdint.h>
extern int x[],y[];
int test(int i)
{
    y[0] = 1;
    uintptr_t px = (uintptr_t)(x+5);
    uintptr_t py = (uintptr_t)(y+i);
    int flag = (px==py);
    if (flag)
        y[i] = 2;
    return y[0];
}

If px and py are coincidentally equal and i is zero, that will cause clang to set y[0] to 2 but return 1. See https://godbolt.org/z/7Sa_KZ for generated code ("mov eax,1 / ret" means "return 1").