Pre-RFC: `usize` semantics

language design Unsafe Code Guidelines
156

Here's my attempt to summarise the discussion. Accurately summarising over 150 replies is hard so there could be things I've missed!

The question that started the thread was, in short, “the current definition of usize doesn't work well on CHERI, can we change it without breaking existing code?” The obvious choices for a 64 bit CHERI target are 64 or 128 bit usize, and the proposed solution was 64 bit. At this point, the answer seems to be that there are a number of unresolved concerns, and there is insufficient consensus to make language or documentation changes.

Specific concerns that were raised which I don't think we have good answers to:

  1. Existing documentation (possibly inconsistently) says that size_of::<usize>() == size_of::<*const T>() (i.e. 128 bits on CHERI). Changing this could weaken confidence in Rust's stability. Maintaining this doesn't work out well for CHERI (degraded indexing efficiency, some code assumes usize is word-sized, some FFI assumes usize == size_t, some code may be assuming pointer as usize only returns an address).
  2. Some code assumes size_of::<usize> == size_of::<*const T> in size or address calculations, which is hard to lint. This only actually becomes a problem when building for CHERI.
  3. Justification for disruptive language changes is limited until CHERI hardware reaches consumers.
  4. Changes to usize could complicate the situation for other proposed targets with complicated address semantics (w65, 8086).

Concerns that I think we have some sort of answer to:

  1. It needs to be clear to crate developers that CHERI support is optional (there are a few options)
  2. CHERI support should be built on strict provenance (yes it should!)

Of more recently, the idea that we could add an experimental tier three CHERI target without committing to semantic changes has been raised. I don't think there were any major objections to this, so it seems like a way forward.

To me, it look like the next thing to do is to talk to the compiler team about what problems need solving for an experimental target to happen. Is a Zulip thread or an MCP the right place to do that?

12 Likes