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

Clarify str::from_utf8_unchecked's invariants #95895

Merged
merged 1 commit into from
Apr 12, 2022
Merged
Changes from all commits
Commits
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
6 changes: 1 addition & 5 deletions library/core/src/str/converts.rs
Original file line number Diff line number Diff line change
Expand Up @@ -144,11 +144,7 @@ pub const fn from_utf8_mut(v: &mut [u8]) -> Result<&mut str, Utf8Error> {
///
/// # Safety
///
/// This function is unsafe because it does not check that the bytes passed to
/// it are valid UTF-8. If this constraint is violated, undefined behavior
/// results, as the rest of Rust assumes that [`&str`]s are valid UTF-8.
///
/// [`&str`]: str
/// The bytes passed in must be valid UTF-8.
Copy link
Member

Choose a reason for hiding this comment

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

This isn't exactly right: A &str is allowed to contain invalid utf-8, but other functions might assume that a &str is valid utf-8, making a non-utf-8 &str very hard to safely use. But just calling this function with invalid utf-8 is, by itself, not unsafe.

See also e.g. https://doc.rust-lang.org/stable/std/string/struct.String.html#method.from_utf8_unchecked

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is true, but this is perhaps even handled just by if the validity of &T is independent from whether the pointee bytes are valid at type T.

In general, from_unchecked functions do just say that it is UB to provide an argument which does not satisfy the safety invariant. This is useful, because it allows a sanitizing implementation of the function which checks the precondition.

A postcondition of "is not used in any way which causes UB" is much more difficult to reason about.

Another point is that str has the option of using &*(v as *const [u8] as *const str) to construct a &str to invalid-UTF-8. String doesn't have any such API, relying on conversion to/from Vec<u8>.

If any str/String methods actually documented that they were safe to call with a reference to invalid UTF-8, then this weaker documentation requirement makes sense. As is, the only possible thing to do with a str/String to invalid UTF-8 is to forget it. With that the case, the clearer precondition seems better to use.

///
/// # Examples
///
Expand Down