std::launder 和严格的别名规则

Question

Consider this code:

void f(char * ptr)
{
    auto int_ptr = reinterpret_cast<int*>(ptr); // <---- line of interest 
    // use int_ptr ... 
}

void example_1()
{
    int i = 10;    
    f(reinterpret_cast<char*>(&i));
}

void example_2()
{
    alignas(alignof(int)) char storage[sizeof(int)];
    new (&storage) int;
    f(storage);
}

Line of interest with call from example_1 :

Q1: On the callside the char pointer is aliasing our integer pointer. This is valid. But is it also valid to just cast it back to an int ? We know an int is within its lifetime there, but consider the function is defined in another translation unit (with no linktime optimization enabled) and the context is not known. Then all the compiler sees is: an int pointer wants to alias a char pointer, and this is violating the strict aliasing rules. So is it allowed?

Q2: Considering it's not allowed. We got std::launder in C++17. It's kind of a pointer optimization barrier mostly used to access an object which got placement new 'ed into the storage of an object of other type or when const members are involved. Can we use it to give the compiler a hint and prevent undefined behavior?

line of interest with call from example_2:

Q3: Here std::launder should be required, since this is the std::launder use case described in Q2, right?

auto int_ptr = std::launder(reinterpret_cast<int*>(ptr));

But consider again f is defined in another translation unit. How can the compiler know about our placement new , which happens on the callside? How can the compiler (only seeing function f ) distinguish between example_1 and example_2 ? Or is all above just hypothetical, since the strict aliasing rule would just rule out everything (remember, char* to int* not allowed) and the compiler can do what it wants?

Follow-up question:

Q4: If all code above is wrong due to aliasing rules, consider changing the function f to take a void pointer:

void f(void* ptr)
{
    auto int_ptr = reinterpret_cast<int*>(ptr); 
    // use int_ptr ... 
}

Then we have no aliasing problem, but still there is the std::launder case for example_2 . Do we have change the callside and rewrite our example_2 function to:

void example_2()
{
    alignas(alignof(int)) char storage[sizeof(int)];
    new (&storage) int;
    f(std::launder(storage));
}

or is std::launder in function f sufficient?

Answer 1

The strict aliasing rule is a restriction on the type of the glvalue actually used to access an object. All that matters for the purpose of that rule are a) the actual type of the object, and b) the type of the glvalue used for the access.

The intermediate casts the pointer travels through are irrelevant, as long as they preserve the pointer value. (This goes both ways; no amount of clever casts - or laundering, for that matter - will cure a strict aliasing violation.)

f is valid as long as ptr actually points to an object of type int , assuming that it accesses that object via int_ptr without further casting.

example_1 is valid as written; the reinterpret_cast s do not change the pointer value.

example_2 is invalid because it gives f a pointer that doesn't actually point to an int object (it points to the out-of-lifetime first element of the storage array). See Is there a (semantic) difference between the return value of placement new and the casted value of its operand?

Answer 2

You need not std::launder within the function f(). Being as universal as possible, the function f() might be used with any pointer: dirty (that needs to be launded) or not. It's known only on a call side, so you must use something like this:

void example_2()
{
    alignas(alignof(int)) char storage[sizeof(int)];
    new (&storage) int;        // char[] has gone, now int there
    f(std::launder(reinterpret_cast<int*>(storage)));  // assiming f(void* p)
}

And the f() itself is another story. As you mentioned, consider f() is placed in a shared library, so there are no any context assumptions at all.