# Pre-RFC: \`usize\` semantics

**URL:** <https://internals.rust-lang.org/t/pre-rfc-usize-semantics/19444>\
**Category:** Unsafe Code Guidelines\
**Created:** [August 29, 2023, 10:42am UTC](https://internals.rust-lang.org/t/pre-rfc-usize-semantics/19444 "2023-08-29T10:42:44Z")\
**Posts on this page:** 1\
**Showing post:** 47

<div class="post-metadata">

**Author:** ![quinedot](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/quinedot/32/7294_2.png) [@quinedot](https://internals.rust-lang.org/u/quinedot)\
**Post date:** [September 4, 2023, 8:44am UTC](https://internals.rust-lang.org/t/pre-rfc-usize-semantics/19444/47 "2023-09-04T08:44:04Z")

</div>

> [@CAD97](#):
>
> Group A is implicitly assuming that `uintaddr_t` C == `uintptr_t` C, as is all of the pre-1.0 discussion about `usize` being pointer-sized;

I'm pretty sure this part is false for the pre-1.0 discussion, there are acknowledgements in the discussion to them being different.\[1\] My _interpretation_ is that they didn't want to be _too_ much more restrictive than C,\[2\] but didn't want the soup of C int types, so the performance hit was worth the cost on "legacy" or exotic systems like a SNES.\[3\] (Some of those making that decision are still around, so there's no reason to rely on my interpretation if you want to ask them.)

I also don't see how it follows for Group A. For example [the w65 platform implementation thread](https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369) wanted the independent `size_t != usize` without changing `usize = uintptr_t`. And also Ralf's comment just above.

> [@CAD97](#):
>
> Here's the thing though: Group A's code is unsound on CHERI _anyway_.

In that case, support for CHERI should definitely be opt in... if ever supported on Rust 1.x.

> [@CAD97](#):
>
> `fuzzy_provenance_casts` would make pointer as usize and usize as pointer into _hard errors_ on any platform which doesn't have `usize` Rust == `size_t` C\</ == `uintaddr_t` C == `uintptr_t` C. Code of all four groups would continue to work, and would fail to compile on the targets where it's a potential issue.

Is this agreed upon generally? I've not gotten this impression re: `fuzzy_provenance_casts` before, but perhaps I just missed it.\[4\]

Let's say I just missed it. Then making `fuzzy_provenance_casts` a hard error\[5\] could basically be an ecosystem split approach, wherein Rust's guarantees without opt-in are extended to `size_t == uintptr_t`. The RFC for such should not be phrased as `usize = size_t`, it should be phrased as `uintptr_t = size_t`. `usize = size_t` follows from the pre-existing `usize = uintptr_t` guarantee. And that would be backwards compatible; the question becomes is the (future-when-`uintptr_t != size_t`-platforms-are-sorta-supported) ecosytem split acceptable.

If it's acceptable, I believe this could be phased in over time in a non-breaking manner.

But I take it that what you actually had in mind is basically what [you were pitching before,](https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369/28) wherein backwards compatibility is not guaranteed but only a "best effort", as per the exceptions listed, and `usize` _is_ redefined. I still don't see how that can be introduced in a non-breaking manner. Or how the benefit of a smaller-than-`usize`-index-integer can be introduced without the redefinition.

* * *

1. Again the portions about pointer size being adequate if not ideal. Maybe I should direct quote my footnotes? 

2. [quote use Rust libraries as a "drop-in replacement" for C, unquote](https://blog.rust-lang.org/2015/05/15/Rust-1.0.html) 

3. CHERI hadn't been pitched at that time. 

4. Citation welcome! 

5. with no other changes like redefining `usize`

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-usize-semantics/19444)._