core: Add core::ffi::c_intptr_t and core::ffi::c_uintptr_t by lygstate · Pull Request #156626 · rust-lang/rust

lygstate · 2026-05-15T22:36:21Z

In summary, I want to give the following conclusion:

usize, isize should be the same with C23's size_t ssize_t as @tgross35 said at comment.
And from https://internals.rust-lang.org/t/pre-rfc-usize-semantics/19444/156
(c_intptr_t, c_uintptr_t) be defined as one alias of (i8, u8), (i16, u16), (i32, u32), (i64, u64), (i128, u128) in core::ffi is enough.
c_ptrdiff_t is very special, can be either ssize_t or intptr_t
Add function expose_addr to pointer Trait for retrieve the raw integer value for the tagged-pointer.

impl *const T {
    fn addr(self) -> usize;
    fn expose_addr (self) -> c_uintptr_t;
    // ...
}

fn cast_between_pointer_uintptr() {
    let my_val = 42;
    let ptr = &my_val as *const i32;

    // Convert pointer to isize
    let tagged_ptr_integer = ptr as c_uintptr_t;
    let ptr2 = tagged_ptr_integer as *const i32;
}

maybe the as operator is enough.
And avoid cast pointer from/to usize/isize by stablize Tracking Issue for strict_provenance_lints

Add a function to convert c_uintptr_t, c_intptr_t back to pointer. Maybe the as operator is enough.
ptraddr_t is just a alias of usize, do not know if this need to be in core::ffi, not part of C standard yet, but Rust is a language for safety, add it into core::ffi seems make sense.
The usage of usize/isize is guard by strict_provenance

Tracking issue: #88345

rustbot · 2026-05-15T22:36:26Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @scottmcm, libs
@scottmcm, libs expanded to 8 candidates

tgross35 · 2026-05-15T23:01:30Z

There are some unresolved questions there that unfortunately haven't made much progress. I'm not sure it's worth adding more types without having a better story there.

lygstate · 2026-05-15T23:10:01Z

There are some unresolved questions there that unfortunately haven't made much progress. I'm not sure it's worth adding more types without having a better story there.

libc is looking for release 1.0 I think it's time to resolve those questions. What's the questions comes from, can you give me the link.

tgross35 · 2026-05-15T23:16:56Z

libc is looking for release 1.0 I think it's time to resolve those questions. What's the questions comes from, can you give me the link.

As far as libc 1.0 is concerned, the only thing I'd like is for the lang team to say that size_t is always usize, if that's something we can rely on, because then we can delete the size_t alias. Anything else is not blocking, we can update aliases if/when things stabilize.

Info is scattered, see discussion around #88345 (comment) https://internals.rust-lang.org/t/pre-rfc-usize-semantics/19444/22, https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Compat.20with.20size_t.2C.20ptrdiff_t.2C.20intptr_t.2C.20fnptr-sized.20int/with/547982505, and a few other places on Zulip.

arichardson · 2026-05-16T17:24:12Z

CC: @xdoardo

tgross35 · 2026-05-16T20:50:51Z

For anybody who has opinions here about CHERI or otherwise, it would be good to hop in to the ongoing discussion at #t-lang > Compat with size_t, ptrdiff_t, intptr_t, fnptr-sized int.

Tracking issue: rust-lang#88345 Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>

…t detail Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>

arichardson

Thanks for this update, I like the transparent struct approach.

View changes since this review

arichardson · 2026-05-20T07:05:30Z

+    assert_eq!(core::mem::size_of::<c_intptr_t>(), core::mem::size_of::<*const ()>());
+    assert_eq!(core::mem::size_of::<c_uintptr_t>(), core::mem::size_of::<*const ()>());
+
+    let ptr = core::ptr::with_exposed_provenance(16_usize);


Suggested change

let ptr = core::ptr::with_exposed_provenance(16_usize);

let ptr = core::ptr::without_provenance(16_usize);

arichardson · 2026-05-20T07:08:13Z

+#[unstable(feature = "c_size_t", issue = "88345")]
+#[rustc_const_unstable(feature = "c_size_t", issue = "88345")]
+impl const TaggedPointer for c_uintptr_t {
+    fn new(ptr: *const ()) -> Self {


I think it would make a lot of sense to add a usize/isize constructor as well that creates a without_provenance pointer. This would make it more ergonomic to call APIs that use something like "valid pointer" or magic integer (e.g. -1).

RalfJung · 2026-05-31T08:06:24Z

(c_intptr_t, c_uintptr_t) be defined as one alias of (i8, u8), (i16, u16), (i32, u32), (i64, u64), (i128, u128) in core::ffi is enough.

So is this a guarantee that it's never (isize, usize)? That seems odd, why exclude that type?

lygstate · 2026-05-31T22:01:34Z

(c_intptr_t, c_uintptr_t) be defined as one alias of (i8, u8), (i16, u16), (i32, u32), (i64, u64), (i128, u128) in core::ffi is enough.

So is this a guarantee that it's never (isize, usize)? That seems odd, why exclude that type?

Now I realized it, when I create this MR, I just followed the ISO-C; maybe we need introduce something like target_address_width, when target_address_width == target_pointer_width, then c_intptr_t::integer and c_uintptr_t::integer is just an alias of (isze, usize), otherwise it's one alias of (i8, u8), (i16, u16), (i32, u32), (i64, u64), (i128, u128)

xdoardo · 2026-06-01T10:02:19Z

maybe we need introduce something like target_address_width, when target_address_width == target_pointer_width

For what it is worth, in the cheri-rust repo we are experimenting with this mechanism too: CHERIoT-Platform/cheri-rust#138. Let me explicitly mention @seharris, who might have interesting comments on this PR.

rust-bors · 2026-06-07T09:30:48Z

☔ The latest upstream changes (presumably #157558) made this pull request unmergeable. Please resolve the merge conflicts.

Mark-Simulacrum · 2026-06-07T13:20:35Z

r? tgross35

I think there's been a bunch of discussion on Zulip and I'm not quite sure what the current state is. I'll move reviewer to you but feel free to re-roll libs or nominate for team(s) -- I suspect we want some kind of approval of the API surface area (libs-api ACP?).

rustbot · 2026-06-07T13:20:39Z

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

lygstate · 2026-06-07T14:47:45Z

I am watching this, waiting for libs-api ACP, do I need create RFC for this?

programmerjake · 2026-06-07T21:34:22Z

    /// Target features on bpf.
    (unstable, bpf_target_feature, "1.54.0", Some(150247)),
+    /// Allows using size_t/ssize_t/uintptr_t/intptr_t/ptrdiff_t.
+    (unstable, c_size_t, "CURRENT_RUSTC_VERSION", Some(88345)),


if this is a library feature, afaik it doesn't need to be added here

View changes since the review

programmerjake · 2026-06-07T21:35:04Z

 //! This module is intentionally standalone to facilitate parsing when retrieving
 //! core C types.

+use crate::mem::{self};


Suggested change

use crate::mem::{self};

use crate::mem;

View changes since the review

programmerjake · 2026-06-07T21:38:33Z

+#[unstable(feature = "c_size_t", issue = "88345")]
+#[repr(transparent)]
+#[derive(Copy, Clone, Debug)]
+pub struct c_intptr_t(*const ());


this definition could have an incorrect ABI on some targets since some targets require integers to be sign/zero-extended to fill a register depending on the type's signedness, but if pointers are smaller than a register there is no way for rustc to know if it should sign or zero-extend.

View changes since the review

Yeah, pointers are not ABI-compatible with any integer type.

Oh, so this is a ABI break, c_intptr_t must be a integer after-all, uintptr_t is ABI in-compatiable with *const () for FFI passing? This is solely for FFI usage, not for writing code. does this will affect FFI-parameter passing? @arichardson , It's you suggested

This type should be defined as a newtype around isize on current targets. If we ever have upstream CHERI support, then on that target it should be a newtype around *const (). That's pretty much exactly what clang does as well.

Oh, I see, so for default, c_intptr_t is just a alais of isize? do I need pub struct c_intptr_t(isze);? The previous one should be compatiable with libc, but we would have non-consistence API cross current targets/(CHERI like targets)

Yeah that's a question for t-libs-api. Should c_intptr_t be an opaque type that can work uniformly across all targets including CHERI, or should it be a type alias that exposes different operations on different targets?

It's probably best to summarize the situation and open question(s) in a t-libs-api ACP. That's how the team will take a look and give feedback on the open question(s).

programmerjake · 2026-06-07T21:42:06Z

+/// For handle interchange of rust `pointer` type and C's `intptr_t` and `uintptr_t` types.
+#[unstable(feature = "c_size_t", issue = "88345")]
+#[rustc_const_unstable(feature = "c_size_t", issue = "88345")]
+pub const trait TaggedPointer {


this trait should probably be sealed

View changes since the review

rustbot assigned Mark-Simulacrum May 15, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 15, 2026