Thank you all for all the feedback. I’ve tried to capture it to the best of my ability in a new wip Draft of a future R1: https://isocpp.org/files/papers/D3248R1.html , which I think its ready for more feedback.

Please review, and let me know if it doesn’t capture your feedback. Main changes (see changelog):
- Recap of C specification of [u]intptr_t, TS6010, and requiring [u]intptr_t in C efforts.
- Impact analysis:
  * On conforming implementations.
  * On non-conforming implementations.

All currently conforming C++ implementations found already provide [u]intptr_t.

The “impact to non-conforming implementations” captures the discussions about:
- header file differences between C and C++, and
- hardware-architectures with memory tagging/capabilities.

Cheers
Gonzalo

From: Martin Uecker <ma.uecker_at_[hidden]>
Date: Thursday, 23. May 2024 at 20:52
To: Corentin <corentin.jabot_at_[hidden]>, WG14/WG21 liaison mailing list <liaison_at_[hidden]>
Cc: Gonzalo Brito <gonzalob_at_[hidden]>
Subject: Re: [isocpp-wg14/wg21-liaison] P3248R0 Require [u]intptr_t
Am Donnerstag, dem 23.05.2024 um 20:36 +0200 schrieb Corentin:
>
>
> On Thu, May 23, 2024, 20:31 Martin Uecker via Liaison <liaison_at_[hidden]> wrote:
> > Am Donnerstag, dem 23.05.2024 um 13:22 -0400 schrieb Bjarne Stroustrup via Liaison:
> > > IMO, CHERI or similar is going to be immensely important in the future
> > > because it is an obvious and elegant solution to key aspects of the
> > > heavily emphasized memory safety issues.
> > >
> > > Caveat: for my PhD, I worked on a distant ancestor to CHERI pioneering
> > > hardware memory controls (the CAP).
> > >
> > > On 5/23/2024 7:58 AM, Corentin via Liaison wrote:
> > > > (As an aside, while I understand there are platforms where uintptr
> > > > would need to be bigger than sizeof(void*)... that's allowed!
> > > > It's what CHERI seem to be doing
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cl.cam.ac.uk%2Ftechreports%2FUCAM-CL-TR-947.pdf&data=05%7C02%7Cgonzalob%40nvidia.com%7Cd0bf1fa8eb6f4dcf9b4808dc7b5965cb%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638520871485026878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DlKDWegMFOOCJc1bkaFDcMzN%2B9%2FCdP0eNOzg16Ld4Yo%3D&reserved=0<https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf> )
> >
> >
> > I don't thinks so. CHERI extends the size of a void*
> > to include space for a capability and uintptr_t then
> > has the same size to make roundtrips possible.
> > And uintptr_t in CHERI is not a true integer type.
>
> Can you define what a "true integer type" is and why you think uintptr_t on cheri isnt one?

uintptr_t is a type that carries the capability whose
validity is ensured using out-of-band flags. This may work most
of the time but it a hack that breaks the usual mathematical
semantics of integers. Transforming the same value may then
not give a valid pointer if some intermediate operation caused
the capability to be lost. This is problematic from a semantical
analysis and optimization point of view.

Martin




>
> Thanks
>
> >
> > Martin
> >
> > > _______________________________________________
> > > Liaison mailing list
> > > Liaison_at_[hidden]
> > > Subscription: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fliaison&data=05%7C02%7Cgonzalob%40nvidia.com%7Cd0bf1fa8eb6f4dcf9b4808dc7b5965cb%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638520871485036625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=q5ySmSxPDJgpn%2BRYm3exBSt3RxAQwSA6bthw0p2IsZs%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/liaison>
> > > Link to this post: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fliaison%2F2024%2F05%2F1419.php&data=05%7C02%7Cgonzalob%40nvidia.com%7Cd0bf1fa8eb6f4dcf9b4808dc7b5965cb%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638520871485044373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BYtJhtxWiFIvbkOM%2FLsSeKONESCa3T2eMVrEive6F4I%3D&reserved=0<http://lists.isocpp.org/liaison/2024/05/1419.php>
> >
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fliaison&data=05%7C02%7Cgonzalob%40nvidia.com%7Cd0bf1fa8eb6f4dcf9b4808dc7b5965cb%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638520871485052168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RB2HPhW%2Fneo0%2FR3X%2FTxFPz9PWkIE0GJOZDLvRaAI6vY%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/liaison>
> > Link to this post: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fliaison%2F2024%2F05%2F1421.php&data=05%7C02%7Cgonzalob%40nvidia.com%7Cd0bf1fa8eb6f4dcf9b4808dc7b5965cb%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638520871485060467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=S3mcksqN6wRlADzkEyGq64B2yLnQkBDl9VMFQB%2FcwRM%3D&reserved=0<http://lists.isocpp.org/liaison/2024/05/1421.php>