bit_cast | bit_cast

Your undefined behaviour is in GetOffset.

This is how pointer subtraction is defined by the standard:

When two pointer expressions P and Q are subtracted, the type of the result is an implementation-defined signed integral type; this type shall be the same type that is defined as std::ptrdiff in the header ([support.types.layout])

• If P and Q both evaluate to null pointer values, the result is 0.
• Otherwise, if P and Q both point to, respectively, array elements i and j of the same array object x, the expression P - Q has the value i - j.
• Otherwise, the behavior is undefined.

And here, P (which has the address of m_object) and Q (which has the address of data) aren't elements of the same array, so this is undefined behaviour.

Addition and subtraction of pointers and integers is also defined in terms of array elements:

When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P.

• If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value.
• Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expression P + J and J + P (Where J has value j point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i-j of x if 0≤i-j≤n.
• Otherwise, the behavior is undefined.

The pointer subtraction happens at offset_address - offset, where P is the address of m_offset and offset is probably some positive number. m_offset is the first element of the array, so i-j < 0

So, the compiler can see that GetPtr returns a pointer relative to the m_offset (in the char[sizeof(Ptr)] array that aliases the object), so it cannot equal the address of data (without UB), and thus an optimizer can replace (rp.get() == &data) with false.

When you use ptrdiff_t, no such restriction on addition or subtraction exists. And though the standard doesn't guarantee that reinterpret_cast(reinterpret_cast(char_pointer) + n) == char_pointer + n (pointers mapping linearly as you would expect) this is what happens when compiling with gcc on common architectures.

Just make an adapter:

Using std::bit_cast:

Try it online!

No. While std::span in C++23 will be defined such that it must be trivially copyable, there is no requirement that any particular span has the same layout of span. And even if it did, you'd still be accessing the objects of type A through a glvalue of type B, which violates strict aliasing if A and B aren't allowed to be accessed that way. And in your example, they are not.

Since this is tagged language-lawyer, here's what the C++ standard has to say about all this.

But what about closure types that capture, how can their objects be constructed?

The actual part of the standard that cppreference link is referencing is [expr.prim.lambda.general] - 7.5.5.1.14:

The closure type associated with a lambda-expression has no default constructor if the lambda-expression has a lambda-capture and a defaulted default constructor otherwise. It has a defaulted copy constructor and a defaulted move constructor ([class.copy.ctor]). It has a deleted copy assignment operator if the lambda-expression has a lambda-capture and defaulted copy and move assignment operators otherwise ([class.copy.assign]).

However, clauses 1 and 2 say:

The type of a lambda-expression (which is also the type of the closure object) is a unique, unnamed non-union class type, called the closure type, whose properties are described below.

The closure type is not an aggregate type. An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program other than by changing: [unrelated stuff]

Which means that (apart from the unrelated exceptions), the described interface of the lambda as stated is exhaustive. Since no other constructors than the default one is listed, then that's the only one that is supposed to be there.

N.B. : A lambda may be equivalent to a class-based functor, but it is not purely syntactical sugar. The compiler/implementation does not need a constructor in order to construct and parametrize the lambda's type. It's just programmers who are prevented from creating instances by the lack of constructors.

As far as extensions go:

But can a compiler provide such constructor as an extension?

Yes. A compiler is allowed to provide this feature as an extension as long as all it does is make programs that would be ill-formed functional.

From [intro.compliance.general] - 4.1.1.8:

A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program. Implementations are required to diagnose programs that use such extensions that are ill-formed according to this document. Having done so, however, they can compile and execute such programs.

However, for the feature at hand, MSVC would be having issues in its implementation as an extension:

1. It should be emmiting a diagnostic.
2. By its own documentation, it should refuse the code when using /permissive-. Yet it does not.

So it looks like MSVC is, either intentionally or not, behaving as if this was part of the language, which is not the case as far as I can tell.

Assuming I understand the question correctly, here is a simpler example:

But is the program well-formed according to the standard ...

The program has undefined behaviour conditional on leeway given to implementors. Particularly conditional on whether the closure type of the lambda

Without reflection, there is no mechanism you can use to determine the layout of a type. You can test layout compatibility, but you cannot determine the layout itself. That is, if they're not layout compatible, you can't determine why they aren't.

Maybe that span implementation puts the size first. Maybe the size is in a base class subobject which can be empty when the size is static. Who knows.

You cannot write code to bit_cast a span. Not code that works across implementations, anyway. And really, there's no point in doing so. You can just give your type the ability to construct itself from an existing span. bit_cast is returning a new object anyway, so it's not like it's going to be faster or something.

Converting the pointer value is irrelevant. What matters is the object. You have a pointer to an object of type X, but the pointer's type is Y. Trying to access the object of type X through a pointer/reference to unrelated type Y is where the UB comes from.

How you obtained those pointers is mostly irrelevant. So bit_cast is no better than reinterpret_cast in this regard.

If there is no sockaddr_in there, then you can't pretend that there is one. However, it's possible that implicit object creation in C++20 already solves this matter, depending on your code. If it does, then it still doesn't matter how you get the pointer.