Description
EDIT: I'm recycling this issue to track how isize
and usize
's layout interact with value layout in general. The old comment can be read below.
The reference of isize
/usize
currently documents the limits of the current implementation in a non-normative way:
- the maximum value size is
isize::max_value()
, - the maximum number of elements in an array is
usize::max_value()
, - the largest pointer offset is
usize::max_value()
.
These limits are unspecified (not implementation-defined), that is, we don't guarantee anything about these and the Rust implementation does not have to document them at all.
Changing these to either implementation defined, or to some guarantee that all implementations must satisfy probably would require an RFC on its own that answers the questions:
- What's the size of the largest Rust value?
- What's the length of the largest Rust array / slice ? Do we differentiatiate between array / slices to ZSTs and non-ZSTs ?
- What's the largest pointer offset ?
These limits could be implementation-defined, unspecified, or set to some value that all implementations must uphold (isize::MAX
, usize::MAX
, etc.). And the trade-offs involved here are, among others, the kinds of code-generation backends Rust can easily support (e.g. LLVM and GCC limit some of these to isize::MAX
, although these might be worked around), the kinds of optimizations these backends can do, and language complexity (e.g. how easy it is for users to write portable code, etc.).
old comment:
Layout isize
/usize
The current reference says that the layout of usize
determines the maximum size of Rust objects (size_of
and size_of_val
return usize), the maximum number of elements in an array ([T; N: usize]
), and how much a pointer of a certain type can be offseted. It also says that the maximum size of any single value must fit within usize to ensure that pointer diff is representable.
There are two issues with this:
-
unclear what's meant by "offseted". Pointer add operates on
usize
, but pointer offset operates onisize
. If by "offseted" we meanptr.add
we should probably be more explicit about this. -
contradiction: we state that the layout of usize determines the maximum size of an object, and then argue that this is to ensure that pointer diff is representable, but AFAICT if the maximum size of an object is larger than
isize
then pointer diff will overflow and is not representable. IIRC @nikomatsakis argued that currently all Rust objects can be at mostisize::max_value()
large because of this, but this is not what the text says.