Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elaborate on the invariants for references-to-slices #121965

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 11 additions & 1 deletion library/core/src/primitive_docs.rs
Expand Up @@ -1387,9 +1387,19 @@ mod prim_usize {}
/// returning values from safe functions; such violations may result in undefined behavior. Where
/// exceptions to this latter requirement exist, they will be called out explicitly in documentation.
///
/// For references to [slices](primitive.slice.html) and [`str`s](primitive.str.html),
/// a consequence of the above is that their lengths must always be short enough that
/// `size_of_val(t) <= isize::MAX`. Said otherwise, for an element type `E` where
/// `size_of::<E>() > 0` (a non-ZST), the length of the slice must never exceed
/// `isize::MAX / size_of::<E>()`. (Raw pointers may have longer lengths, but
/// references must not. For example, compare the documentation of
/// [`ptr::slice_from_raw_parts`](ptr/fn.slice_from_raw_parts.html) and
/// [`slice::from_raw_parts`](slice/fn.from_raw_parts.html).)
Copy link
Member

@RalfJung RalfJung Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this meant to apply to all types with slice tails, or deliberately restricted to only slices and str?

In &(i32, [i32]), is the max length reduced by one to make sure that the entire type always fits into isize?

///
/// It is not decided yet whether unsafe code may violate these invariants temporarily on internal
/// data. As a consequence, unsafe code which violates these invariants temporarily on internal data
/// may become unsound in future versions of Rust depending on how this question is decided.
/// may already be unsound in current versions of Rust, and additional violations may become unsound
/// in future versions of Rust depending on how this question is decided.
///
/// [allocated object]: ptr#allocated-object
#[stable(feature = "rust1", since = "1.0.0")]
Expand Down