This uintfptr_t thing seems like a pretty reasonable addition to the
standard, though coordination with WG14 is needed.

How about reaching out to people who might be interested in championing
that proposal and co-authoring with them, or championing it yourself? That
might actually get this idea standardized.

Making "demands" on a mailing list doesn't.

On Mon, 17 Aug 2026 at 15:12, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Normally this mailing list is for proposals, and people get a P number
> for their document.
>
> On this occasion though, rather than putting forward a proposal, I am
> making a demand, and my document shall therefore get a D number.
>
> There has been a gaping hole in the Standard for decades now. We have
> uintptr_t for storing a data pointer as an integer, but we don't have
> uintfptr_t to store a code pointer as an integer.
>
> For decades, people have been using uintptr_t in scenarios where they
> really needed uintfptr_t. This is an obscenity which needs to be
> corrected, especially given the advent of the new "-m32df" ABI for the
> GNU compiler.
>
> The new "-m32df" ABI has 32-Bit data pointers and 64-Bit code
> pointers. Code pointers are twice as wide because the higher 32 bits
> correspond to a custom stack, as can be seen here:
>
> https://godbolt.org/z/85er78x5Y
>
> Therefore I demand the addition of uintfptr_t to the language.
>
> Furthermore I have a proposal. I propose the following new type:
>
> uintp_t
>
> uintp_t will be used to store either a code pointer or a data pointer
> (i.e. it is the wider of uintptr_t and uintfptr_t).
>
> Also I propose their signed equivalents: intfptr_t, intp_t
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>