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.

Sign up for GitHub

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

Jump to bottom

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

Closed
wants to merge 1 commit into from
Closed

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion library/core/src/primitive_docs.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
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.
Copy link
Member

Choose a reason for hiding this comment

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

Note that the section you are editing here is talking about the safety invariant, not the validity invariant.

Copy link
Member

Choose a reason for hiding this comment

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

So... the PR diff seems fine to me, except that it doesn't match the PR description (I don't see a validity invariant being defined here), and I am not sure if spelling out this consequence of the previous definition in so many words is all that useful?

If this intends to talk about the validity invariant, then IMO there should be separate subsections for safety and validity invariant, so that is is clear that we are talking about two different invariants.

///
/// 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 •
edited
Loading

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
Loading