From 5634491f3f552cfdbe6b2d696832f545ca12b0a0 Mon Sep 17 00:00:00 2001 From: pwbh <127856937+pwbh@users.noreply.github.com> Date: Sat, 7 Oct 2023 14:07:08 +0300 Subject: [PATCH 1/5] Added text related to handling dropping in raw vec for ZSTs --- src/vec/vec-zsts.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/vec/vec-zsts.md b/src/vec/vec-zsts.md index 6715f947..657ba9ce 100644 --- a/src/vec/vec-zsts.md +++ b/src/vec/vec-zsts.md @@ -214,3 +214,22 @@ impl DoubleEndedIterator for RawValIter { ``` And that's it. Iteration works! + +And that's it. Iteration works! + +One last thing that we need to take into account, is that now when our vec gets dropped it deallocates the memory that was allocated during the time our vec was alive. With ZSTs we did not allocate any memory, and infact we never do. So right now we have unsoundness in our code where we still try deallocate a `NonNull::dangling()` ptr that we use to simulate the ZST in our vec, This means that we would cause an undefined behaviour if we try to deallocate something that we never allocated (obviously and for the right reasons). Lets fix tha, in our raw_vec we are going to tweak our Drop trait and check that we deallocate only types that are sized. + +```rust,ignore +impl Drop for RawVec { + fn drop(&mut self) { + println!("RawVec Drop called, deallocating memory"); + if self.cap != 0 && std::mem::size_of::() > 0 { + let layout = std::alloc::Layout::array::(self.cap).unwrap(); + unsafe { + std::alloc::dealloc(self.ptr.as_ptr() as *mut _, layout); + } + } + } +} +``` + From c50c194f23715ed209e302ceb45900093f798184 Mon Sep 17 00:00:00 2001 From: pwbh <127856937+pwbh@users.noreply.github.com> Date: Sat, 7 Oct 2023 14:07:48 +0300 Subject: [PATCH 2/5] remove duplicate of a sentence --- src/vec/vec-zsts.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/src/vec/vec-zsts.md b/src/vec/vec-zsts.md index 657ba9ce..20a40548 100644 --- a/src/vec/vec-zsts.md +++ b/src/vec/vec-zsts.md @@ -1,13 +1,13 @@ # Handling Zero-Sized Types It's time. We're going to fight the specter that is zero-sized types. Safe Rust -*never* needs to care about this, but Vec is very intensive on raw pointers and +_never_ needs to care about this, but Vec is very intensive on raw pointers and raw allocations, which are exactly the two things that care about zero-sized types. We need to be careful of two things: -* The raw allocator API has undefined behavior if you pass in 0 for an +- The raw allocator API has undefined behavior if you pass in 0 for an allocation size. -* raw pointer offsets are no-ops for zero-sized types, which will break our +- raw pointer offsets are no-ops for zero-sized types, which will break our C-style pointer iterator. Thankfully we abstracted out pointer-iterators and allocating handling into @@ -30,6 +30,7 @@ Due to our current architecture, all this means is writing 3 guards, one in each method of `RawVec`. + ```rust,ignore impl RawVec { fn new() -> Self { @@ -108,6 +109,7 @@ nothing. The current solution to this is to cast the pointers to integers, increment, and then cast them back: + ```rust,ignore impl RawValIter { unsafe fn new(slice: &[T]) -> Self { @@ -126,12 +128,13 @@ impl RawValIter { ``` Now we have a different bug. Instead of our iterators not running at all, our -iterators now run *forever*. We need to do the same trick in our iterator impls. +iterators now run _forever_. We need to do the same trick in our iterator impls. Also, our size_hint computation code will divide by 0 for ZSTs. Since we'll basically be treating the two pointers as if they point to bytes, we'll just map size 0 to divide by 1. Here's what `next` will be: + ```rust,ignore fn next(&mut self) -> Option { if self.start == self.end { @@ -152,13 +155,13 @@ fn next(&mut self) -> Option { Do you see the "bug"? No one else did! The original author only noticed the problem when linking to this page years later. This code is kind of dubious -because abusing the iterator pointers to be *counters* makes them unaligned! -Our *one job* when using ZSTs is to keep pointers aligned! *forehead slap* +because abusing the iterator pointers to be _counters_ makes them unaligned! +Our _one job_ when using ZSTs is to keep pointers aligned! _forehead slap_ Raw pointers don't need to be aligned at all times, so the basic trick of -using pointers as counters is *fine*, but they *should* definitely be aligned -when passed to `ptr::read`! This is *possibly* needless pedantry -because `ptr::read` is a noop for a ZST, but let's be a *little* more +using pointers as counters is _fine_, but they _should_ definitely be aligned +when passed to `ptr::read`! This is _possibly_ needless pedantry +because `ptr::read` is a noop for a ZST, but let's be a _little_ more responsible and read from `NonNull::dangling` on the ZST path. (Alternatively you could call `read_unaligned` on the ZST path. Either is fine, @@ -166,6 +169,7 @@ because either way we're making up a value from nothing and it all compiles to doing nothing.) + ```rust,ignore impl Iterator for RawValIter { type Item = T; @@ -215,8 +219,6 @@ impl DoubleEndedIterator for RawValIter { And that's it. Iteration works! -And that's it. Iteration works! - One last thing that we need to take into account, is that now when our vec gets dropped it deallocates the memory that was allocated during the time our vec was alive. With ZSTs we did not allocate any memory, and infact we never do. So right now we have unsoundness in our code where we still try deallocate a `NonNull::dangling()` ptr that we use to simulate the ZST in our vec, This means that we would cause an undefined behaviour if we try to deallocate something that we never allocated (obviously and for the right reasons). Lets fix tha, in our raw_vec we are going to tweak our Drop trait and check that we deallocate only types that are sized. ```rust,ignore @@ -232,4 +234,3 @@ impl Drop for RawVec { } } ``` - From 82470abc9f3d5008881782154931ae3bc0b5eaf4 Mon Sep 17 00:00:00 2001 From: pwbh <127856937+pwbh@users.noreply.github.com> Date: Sat, 7 Oct 2023 14:08:12 +0300 Subject: [PATCH 3/5] Revert "remove duplicate of a sentence" This reverts commit c50c194f23715ed209e302ceb45900093f798184. --- src/vec/vec-zsts.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/src/vec/vec-zsts.md b/src/vec/vec-zsts.md index 20a40548..657ba9ce 100644 --- a/src/vec/vec-zsts.md +++ b/src/vec/vec-zsts.md @@ -1,13 +1,13 @@ # Handling Zero-Sized Types It's time. We're going to fight the specter that is zero-sized types. Safe Rust -_never_ needs to care about this, but Vec is very intensive on raw pointers and +*never* needs to care about this, but Vec is very intensive on raw pointers and raw allocations, which are exactly the two things that care about zero-sized types. We need to be careful of two things: -- The raw allocator API has undefined behavior if you pass in 0 for an +* The raw allocator API has undefined behavior if you pass in 0 for an allocation size. -- raw pointer offsets are no-ops for zero-sized types, which will break our +* raw pointer offsets are no-ops for zero-sized types, which will break our C-style pointer iterator. Thankfully we abstracted out pointer-iterators and allocating handling into @@ -30,7 +30,6 @@ Due to our current architecture, all this means is writing 3 guards, one in each method of `RawVec`. - ```rust,ignore impl RawVec { fn new() -> Self { @@ -109,7 +108,6 @@ nothing. The current solution to this is to cast the pointers to integers, increment, and then cast them back: - ```rust,ignore impl RawValIter { unsafe fn new(slice: &[T]) -> Self { @@ -128,13 +126,12 @@ impl RawValIter { ``` Now we have a different bug. Instead of our iterators not running at all, our -iterators now run _forever_. We need to do the same trick in our iterator impls. +iterators now run *forever*. We need to do the same trick in our iterator impls. Also, our size_hint computation code will divide by 0 for ZSTs. Since we'll basically be treating the two pointers as if they point to bytes, we'll just map size 0 to divide by 1. Here's what `next` will be: - ```rust,ignore fn next(&mut self) -> Option { if self.start == self.end { @@ -155,13 +152,13 @@ fn next(&mut self) -> Option { Do you see the "bug"? No one else did! The original author only noticed the problem when linking to this page years later. This code is kind of dubious -because abusing the iterator pointers to be _counters_ makes them unaligned! -Our _one job_ when using ZSTs is to keep pointers aligned! _forehead slap_ +because abusing the iterator pointers to be *counters* makes them unaligned! +Our *one job* when using ZSTs is to keep pointers aligned! *forehead slap* Raw pointers don't need to be aligned at all times, so the basic trick of -using pointers as counters is _fine_, but they _should_ definitely be aligned -when passed to `ptr::read`! This is _possibly_ needless pedantry -because `ptr::read` is a noop for a ZST, but let's be a _little_ more +using pointers as counters is *fine*, but they *should* definitely be aligned +when passed to `ptr::read`! This is *possibly* needless pedantry +because `ptr::read` is a noop for a ZST, but let's be a *little* more responsible and read from `NonNull::dangling` on the ZST path. (Alternatively you could call `read_unaligned` on the ZST path. Either is fine, @@ -169,7 +166,6 @@ because either way we're making up a value from nothing and it all compiles to doing nothing.) - ```rust,ignore impl Iterator for RawValIter { type Item = T; @@ -219,6 +215,8 @@ impl DoubleEndedIterator for RawValIter { And that's it. Iteration works! +And that's it. Iteration works! + One last thing that we need to take into account, is that now when our vec gets dropped it deallocates the memory that was allocated during the time our vec was alive. With ZSTs we did not allocate any memory, and infact we never do. So right now we have unsoundness in our code where we still try deallocate a `NonNull::dangling()` ptr that we use to simulate the ZST in our vec, This means that we would cause an undefined behaviour if we try to deallocate something that we never allocated (obviously and for the right reasons). Lets fix tha, in our raw_vec we are going to tweak our Drop trait and check that we deallocate only types that are sized. ```rust,ignore @@ -234,3 +232,4 @@ impl Drop for RawVec { } } ``` + From f111ae96d993de4a763691317f8c56b66ae1cef5 Mon Sep 17 00:00:00 2001 From: pwbh <127856937+pwbh@users.noreply.github.com> Date: Sat, 7 Oct 2023 14:08:39 +0300 Subject: [PATCH 4/5] remove duplication --- src/vec/vec-zsts.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/vec/vec-zsts.md b/src/vec/vec-zsts.md index 657ba9ce..97787594 100644 --- a/src/vec/vec-zsts.md +++ b/src/vec/vec-zsts.md @@ -215,8 +215,6 @@ impl DoubleEndedIterator for RawValIter { And that's it. Iteration works! -And that's it. Iteration works! - One last thing that we need to take into account, is that now when our vec gets dropped it deallocates the memory that was allocated during the time our vec was alive. With ZSTs we did not allocate any memory, and infact we never do. So right now we have unsoundness in our code where we still try deallocate a `NonNull::dangling()` ptr that we use to simulate the ZST in our vec, This means that we would cause an undefined behaviour if we try to deallocate something that we never allocated (obviously and for the right reasons). Lets fix tha, in our raw_vec we are going to tweak our Drop trait and check that we deallocate only types that are sized. ```rust,ignore From 73df70d8cb8a094215085aa1edcc85977d46f7a9 Mon Sep 17 00:00:00 2001 From: pwbh <127856937+pwbh@users.noreply.github.com> Date: Sat, 7 Oct 2023 14:09:34 +0300 Subject: [PATCH 5/5] remove comma --- src/vec/vec-zsts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vec/vec-zsts.md b/src/vec/vec-zsts.md index 97787594..d23ca404 100644 --- a/src/vec/vec-zsts.md +++ b/src/vec/vec-zsts.md @@ -215,7 +215,7 @@ impl DoubleEndedIterator for RawValIter { And that's it. Iteration works! -One last thing that we need to take into account, is that now when our vec gets dropped it deallocates the memory that was allocated during the time our vec was alive. With ZSTs we did not allocate any memory, and infact we never do. So right now we have unsoundness in our code where we still try deallocate a `NonNull::dangling()` ptr that we use to simulate the ZST in our vec, This means that we would cause an undefined behaviour if we try to deallocate something that we never allocated (obviously and for the right reasons). Lets fix tha, in our raw_vec we are going to tweak our Drop trait and check that we deallocate only types that are sized. +One last thing that we need to take into account is that now when our vec gets dropped it deallocates the memory that was allocated during the time our vec was alive. With ZSTs we did not allocate any memory, and infact we never do. So right now we have unsoundness in our code where we still try deallocate a `NonNull::dangling()` ptr that we use to simulate the ZST in our vec, This means that we would cause an undefined behaviour if we try to deallocate something that we never allocated (obviously and for the right reasons). Lets fix tha, in our raw_vec we are going to tweak our Drop trait and check that we deallocate only types that are sized. ```rust,ignore impl Drop for RawVec {