On 2025-07-02 at 17:33, Frederick Virchanza Gotham via Std-Proposals wrote:
> First let's talk about uintfuncptr_t.
>
> The Standard says that the address of any non-member function can be
> safely cast to:
>
> void(*)(void)
>
> and then back to the original function pointer type without any loss
> of information. So we already have a 'unified' function pointer type.
> There should be an integer type corresponding to this, and it should
> be std::uintfuncptr_t.
>
> So that's code memory dealt with.
>
> Moving onto data memory now . . . which by the way might need bigger
> or smaller pointers than code memory (e.g. Harvard Architecture).
>
> Let's talk about uintptr_t, and about why it's optional for compilers
> to provide. I've written assembler for around about five or six CPU
> instructions sets, and all these machines always treat a pointer just
> like an integer.

So, just add a static_cast to your code documenting your assumptions.
Anyone - hypothetically(?) - finding a system where it doesn't hold will
surely report back to you.

Why change the standard for something that supposedly never happens?