-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Update Box::from_raw example to generalize better #73678
Conversation
I know very little about rust, so I saw this example and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I also added a comment that explains why `.write` is used, but I think adding that comment is optional and may be too verbose here. I do however think that changing this example is a good idea to suggest the correct generalization. `.write` is also used in most of the rest of the documentation here, even if the example is `i32`, so it would additionally be more consistent.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @LukasKalbertodt (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a bunch, this is a good doc change! I also like the comment :)
@bors r+ rollup |
📌 Commit 0c88dd6 has been approved by |
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
Update Box::from_raw example to generalize better I know very little about rust, so I saw the example here ``` use std::alloc::{alloc, Layout}; unsafe { let ptr = alloc(Layout::new::<i32>()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing, ``` let layout = Layout::new::<T>(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T`, which ended up crashing with SIGSEGV, because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file, which use `.write`. I also added a comment to explain it, but I'm not too attached to that, and can see it being too verbose in this place.
…arth Rollup of 17 pull requests Successful merges: - rust-lang#72071 (Added detailed error code explanation for issue E0687 in Rust compiler.) - rust-lang#72369 (Bring net/parser.rs up to modern up to date with modern rust patterns) - rust-lang#72445 (Stabilize `#[track_caller]`.) - rust-lang#73466 (impl From<char> for String) - rust-lang#73548 (remove rustdoc warnings) - rust-lang#73649 (Fix sentence structure) - rust-lang#73678 (Update Box::from_raw example to generalize better) - rust-lang#73705 (stop taking references in Relate) - rust-lang#73716 (Document the static keyword) - rust-lang#73752 (Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other) - rust-lang#73776 (Move terminator to new module) - rust-lang#73778 (Make `likely` and `unlikely` const, gated by feature `const_unlikely`) - rust-lang#73805 (Document the type keyword) - rust-lang#73806 (Use an 'approximate' universal upper bound when reporting region errors) - rust-lang#73828 (Fix wording for anonymous parameter name help) - rust-lang#73846 (Fix comma in debug_assert! docs) - rust-lang#73847 (Edit cursor.prev() method docs in lexer) Failed merges: r? @ghost
I know very little about rust, so I saw the example here
and tried to generalize it by writing,
for some more complicated
T
, which ended up crashing with SIGSEGV,because it tried to
drop_in_place
the previous object inptr
which isof course garbage. I think that changing this example to use
.write
insteadwould be a good idea to suggest the correct generalization. It is also more
consistent with other documentation items in this file, which use
.write
.I also added a comment to explain it, but I'm not too attached to that,
and can see it being too verbose in this place.