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

Are the #![feature(layout_for_ptr)] functions sound to call on invalid data pointers? #86602

Open
repnop opened this issue Jun 24, 2021 · 3 comments
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-raw-pointers Area: raw pointers, MaybeUninit, NonNull C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@repnop
Copy link
Contributor

repnop commented Jun 24, 2021

Reading the documentation for the #![feature(layout_for_ptr)] functions, it doesn't mention if it accepts invalid data pointer values (e.g. a pointer created with core::ptr::null()), but seems to suggest that it does:

If T is Sized, this function is always safe to call.

but there's a comment mentioning that the pointer must be valid inside the functions, e.g.:

pub const unsafe fn size_of_val_raw<T: ?Sized>(val: *const T) -> usize {
// SAFETY: the caller must provide a valid raw pointer
unsafe { intrinsics::size_of_val(val) }
}

I would think that the answer is yes since its operating on the metadata of the pointer and not the pointer value itself (and with my limited testing, this seems like the current behavior). However, in either case I think its worth explicitly mentioning the validity of the pointer in the documentation for the functions.

@memoryruins
Copy link
Contributor

@rustbot label +A-docs +C-enhancement +T-libs-api +A-raw-pointers

@BoxyUwU BoxyUwU added A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-raw-pointers Area: raw pointers, MaybeUninit, NonNull C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jun 24, 2021
@asquared31415
Copy link
Contributor

asquared31415 commented Jun 24, 2021

playground link demonstrating that the metadata is read correctly despite the pointer being invalid in the traditional sense

This uses an unsized slice pointer though, where the requirements are

then the length of the slice tail must be an initialized integer, and the size of the entire value (dynamic tail length + statically sized prefix) must fit in isize.

@RalfJung
Copy link
Member

RalfJung commented Jun 26, 2021

but there's a comment mentioning that the pointer must be valid inside the functions, e.g.:

Yes, the caller must provide a valid raw pointer. Which values are valid for which type is documented in the reference.

despite the pointer being invalid in the traditional sense

The issue is that "(in)valid" are horribly overloaded terms. :/ But in this comment it is a technical term as explained in this blog post. Your pointer might be dangling, but as a raw pointer, it is still "valid" (as a reference, it would not be "valid" -- validity is a type-relative property).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-raw-pointers Area: raw pointers, MaybeUninit, NonNull C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants