-
Notifications
You must be signed in to change notification settings - Fork 2
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
Use NonNull
#2
Use NonNull
#2
Conversation
I know that
You mean taking multiple |
The issue was that if |
Ok. But what about calling |
No, that's fine — even though it's invalid you're not reading any bytes so it's OK. |
As a side-effect this fixes an unsoundness by correctly handling allocation errors. Additionally, it fixes the UB of taking multiple unique references to `ZST_SLICE` by using `NonNull::dangling()` instead.
But if follow that logic, aren't multiple references to |
No, because a unique reference asserts that no other unique references exist to the same location, whether or not you use the reference. fn unsound() {
static mut X: [u8; 1] = [0];
// It is not sound to create multiple unique references to the same
// location if it is not a ZST.
unsafe { &mut X };
}
fn sound() {
// It is sound to create multiple unique references to the same
// location if they come from different places and are ZSTs
unsafe { <NonNull<[u8; 0]>>::dangling().as_mut() };
} |
Wait a minute.
It was:
That would be OK? Were I can read about multi &mut ZST references? |
I am not quite sure on that, but it should definitely be avoided since we have a better alternative that is definitely sound.
I found this issue which might be interesting. |
Thank you for this PR! |
This allows
Option<AnyVec>
to have the same size asAnyVec
. But the main reason I did this was to fix the null pointer deref that can occur when allocation fails by using the type-system to force us to handle that case withhandle_alloc_error
. Additionally, it fixes the UB of taking multiple unique references toZST_SLICE
by usingNonNull::dangling()
instead.