Forgot to explain why casting from function pointer to non const object _should_ be okay. But while thinking about it, I noticed a loophole in my reasoning. Actually, the most sensible semantics would be to reject such a cast, as it makes it possible to cast away const on an object via a function pointer type.

If the originating pointee is a function, access through object type is already an aliasing UB.
```
// 2) function pointer -> non const object
// pointer
void f();
// ok: we cast away const, but see below
int* pi = reinterpret_cast<int*>(&f);
// two UB: strict aliasing and cv-ness
*pi = 0;
// UB: strict aliasing
int j = *pi;
```
But we can't know in general if a function pointer would actually hold a pointer to an object.
```
int const i;
// ok: function pointers are 'logically const'
void(* pf)() = reinterpret_cast<void(*)()>(&i);

// bad: cast away const on the original int
int* pi = reinterpret_cast<int*>(pf);
```
In summary, the most conservative approach would be for a compiler to reject conversions from function pointer -> non const object pointer. Similarly, reject volatile object pointer to function pointer. As an exceptional case, a compiler could permit the function pointer -> non const object if it can prove or deduce that the pointer denotes a function (this can happen if it is the address of a function, but also if the original pointer value is used with a call operator).

On April 27, 2023 3:16:53 p.m. EDT, "Julien Villemure-Fréchette" <julien.villemure@hotmail.com> wrote:

cv qualifiers are always discarded on function types, they have no effect:
```
using ft = void();
using cft = const cft;

static_assert(std::is_same_v<ft, cft>); // passes
```
Hence, there are no type reference/pointers to const function. Function types are not object types, and cannot be assigned to, and their concrete representation cannot change at runtime: in a sense, they are always 'logically const' (and never 'logically volatile'). Since there is no reasonable semantics for runtime modification of a function's source code, having cv qualifiers on them seems superfluous.

With respect to this view, it seems logical to say that casting to a function type does not cast away const (but does cast away volatile). Conversely, casting from function type to void* could be viewed as casting away const. This boils down to 2 possible 'cv violations', but only one which could actually lead to a cv related UB without first encountering a strict aliasing UB:

```
void f();

// 1) volatile object pointer -> function pointer
volatile int i;
// bad: cast away volatile
auto* pf = reinterpret_cast<void(*)()>(&i);
// Ok
int const* pi = reinterpret_cast<int const*>(pf);

// UB: access to volatile object through non
// volatile lvalue. The first cast should be made
// illegal
int j = *pi;

// 2) function pointer -> non const object
// pointer
void f();
// ok: we cast away const, but see below
int* pi = reinterpret_cast<int*>(&f);

```
This would seem like reasonable implementation, but is not mandated by the standard, and I think implementation are free to document how they support conversion to/from function pointer an object pointers.

I didn't go through explaining member function pointers; but they behave the same with respect to cv-ness. Although, their syntax is a different beast. Unlike function types, there exist no member function types, nor reference to member function types, so it is impossible to name or declare a 'const member function' type (the const qualifier appearing after the argument list is completely unrelated as it applies to the implicit 'this' and has no relationship on the constness of a pointed to member function.

On April 26, 2023 7:19:26 p.m. EDT, Myria via Std-Discussion <std-discussion@lists.isocpp.org> wrote:

C++ says that reinterpret_casting an object pointer to a function pointer is conditionally supported. However, there seems to be implementation divergence on what happens if the object pointer is cv-qualified. GCC allows casts from cv object * to function pointer, but Clang and Visual C++ do not.

I mentioned this some years ago as a possible defect report, and I sent a request for one, but it never got filed.

Should something like this be a defect report? What is the correct interpretation of the Standard on this? Being a conditionally supported operation, is either interpretation allowed?

[expr.reinterpret.cast]/2 says that reinterpret_cast "shall not cast away constness". But is casting to function pointer type removing constness? [expr.reinterpret.cast]/8 mentions the possibility of cv-qualified casts in the other direction.

Function types have no cv qualification in the normal sense. A cv-qualified member function is referring to the "this" parameter, not the constness of the function itself. Is a cast to function type removing a cv qualifier when functions having them is nonsensical to begin with?

#include <cstdint>
#include <cstdio>

#if !defined(__x86_64__) && !defined(_M_X64)
#error "This is an x86-64-only program"
#endif

#ifdef _MSC_VER
#pragma code_seg(push, ".text")
#pragma code_seg(pop)
#define EXECUTABLE_SEGMENT __declspec(allocate(".text"))
#elif defined(__linux__)
#define EXECUTABLE_SEGMENT [[gnu::section(".text.meow")]]
#else
#error "Unknown platform"
#endif

// movl $0x12345678, %eax
// ret
EXECUTABLE_SEGMENT const std::uint8_t s_code[] =
{
0xB8, 0x78, 0x56, 0x34, 0x12, 0xC3
};

int main()
{
// an intervening std::uintptr_t cast works with all compilers relevant here
int result = reinterpret_cast<int (*)()>(s_code)();
std::printf("%08X\n", result);
return 0;
}

Melissa