> One of the concerns I recall was around implementations supporting very wide pointer types, such as capability-based memory architectures.

On mainstream platforms, like Linux, some capability-based architectures already do provide “uintptr_t” with C semantics, because otherwise all pre-existing SW, which assumes this type is available, doesn’t work. This paper captures one concern some implementors of these architectures have: C and C++ lack an integer type suitable for holding a “pointer address” which, on their platforms, is half the size of “pointer value” (uintptr_t) and has functional implications. The C standard libraries of some of these capability-based architectures do provide an integer type capable of holding a “pointer address” as an extension (this paper refers to, e.g., glibc stddef “ptraddr_t” provided for Arm CHERI on Linux).

This concern is not about “uintptr_t” per-se, but about C and C++ missing adjacent features that these architectures need. Requiring “uintptr_t” is not incompatible with adding these features.

That’s the only concern I am aware of (and is captured in the “Usage Guideline” section of the paper).

Aaron, if you are aware of another concern related to these architectures, could you either put me in contact with those that raised the concern, or if the concern is captured somewhere, share it either in this thread, or with me privately, so that we can capture it in the paper and ensure these architectures continue to work?

Thank you!
Gonzalo

From: Aaron Ballman <aaron_at_aaronballman.com>
Date: Thursday, 23. May 2024 at 14:58
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: liaison_at_lists.isocpp.org <liaison_at_[hidden]>, Gonzalo Brito <gonzalob_at_[hidden]>
Subject: Re: [isocpp-wg14/wg21-liaison] P3248R0 Require [u]intptr_t
On Thu, May 23, 2024 at 7:55 AM Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Thu, 23 May 2024 at 14:47, Aaron Ballman via Liaison
> <liaison_at_[hidden]> wrote:
> >
> > On Thu, May 23, 2024 at 7:24 AM Robert Seacord via Liaison
> > <liaison_at_[hidden]> wrote:
> > >
> > > I cannot think of any reasons why this paper would cause any C/C++ compatibility issues.
> >
> > Aside from it meaning these C interfaces are mandatory in C++ but
> > optional in C. ;-)
>
> In <cstdint>, which is a C++ header and not a C header.
>
> I don't see a compatibility issue in this.

Committee members sometimes understand that the `<cfoo>` headers are
not feature-compatible with the <foo.h> headers in C; but my
experience with users is that they don't always see that distinction
so clearly. It's hard to explain to a user why:

#include <stdint.h>
intptr_t val;

doesn't compile for them in C++ while

#include <cstdint>
intptr_t val;

does, especially when C++ specifies that users who need their C++ code
to compile with a C compiler should use the C headers. That's where I
see the incompatibility. Also, WG14 rejected the paper because
implementers said they couldn't support it (see the minutes of the
discussion at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn3036.pdf&data=05%7C02%7Cgonzalob%40nvidia.com%7C687365407f4747dd1eb108dc7b27ead1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638520659088028654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=YjdKyo3o4J4MhMsSx2UHvTyYPeBH9Pm%2BYKqcfjf8UCo%3D&reserved=0)<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3036.pdf>
-- instead we put it into TS 6010 so we could explore in more detail
whether it's possible to support. FWIW, Clang has no problems
supporting mandatory intptr_t to my knowledge.

~Aaron