-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Added minor clarification to specification of GlobalAlloc::realloc. #68381
Conversation
The `layout` for the returned allocation of a `realloc` is only implicitly specified. This change makes it explicit.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cramertj (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. |
@bors r+ rollup |
📌 Commit 6be3446 has been approved by |
Added minor clarification to specification of GlobalAlloc::realloc. The specification of `realloc` is slightly unclear: ``` /// * `layout` must be the same layout that was used /// to allocate that block of memory, ``` https://github.com/rust-lang/rust/blob/master/src/libcore/alloc.rs#L541-L542 In the case of an `alloc` or `alloc_zeroed` this is fairly evidently the `layout` parameter passed into the original call. In the case of a `realloc`, this I assume is `layout` modified to contain `new_size`. However, I could not find this case specified in the documentation. Thus technically in a sequence of calls to `realloc`, it would be valid to provide the second call to `realloc` the same `layout` as the first call to `realloc`, which is almost certainly not going to be handled correctly. This PR attempts to clarify the specification.
Added minor clarification to specification of GlobalAlloc::realloc. The specification of `realloc` is slightly unclear: ``` /// * `layout` must be the same layout that was used /// to allocate that block of memory, ``` https://github.com/rust-lang/rust/blob/master/src/libcore/alloc.rs#L541-L542 In the case of an `alloc` or `alloc_zeroed` this is fairly evidently the `layout` parameter passed into the original call. In the case of a `realloc`, this I assume is `layout` modified to contain `new_size`. However, I could not find this case specified in the documentation. Thus technically in a sequence of calls to `realloc`, it would be valid to provide the second call to `realloc` the same `layout` as the first call to `realloc`, which is almost certainly not going to be handled correctly. This PR attempts to clarify the specification.
Rollup of 8 pull requests Successful merges: - #67734 (Remove appendix from Apache license) - #67795 (Cleanup formatting code) - #68290 (Fix some tests failing in `--pass check` mode) - #68297 ( Filter and test predicates using `normalize_and_test_predicates` for const-prop) - #68302 (Fix #[track_caller] and function pointers) - #68339 (Add `riscv64gc-unknown-linux-gnu` into target list in build-manifest) - #68381 (Added minor clarification to specification of GlobalAlloc::realloc.) - #68397 (rustdoc: Correct order of `async` and `unsafe` in `async unsafe fn`s) Failed merges: r? @ghost
The specification of
realloc
is slightly unclear:https://github.com/rust-lang/rust/blob/master/src/libcore/alloc.rs#L541-L542
In the case of an
alloc
oralloc_zeroed
this is fairly evidently thelayout
parameter passed into the original call. In the case of arealloc
, this I assume islayout
modified to containnew_size
. However, I could not find this case specified in the documentation. Thus technically in a sequence of calls torealloc
, it would be valid to provide the second call torealloc
the samelayout
as the first call torealloc
, which is almost certainly not going to be handled correctly.This PR attempts to clarify the specification.