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

Added minor clarification to specification of GlobalAlloc::realloc. #68381

Merged
merged 1 commit into from
Jan 21, 2020

Conversation

mjp41
Copy link
Contributor

@mjp41 mjp41 commented Jan 20, 2020

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.

The `layout` for the returned allocation of a `realloc` is
only implicitly specified.  This change makes it explicit.
@rust-highfive
Copy link
Collaborator

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.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 20, 2020
@Dylan-DPC-zz
Copy link

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jan 20, 2020

📌 Commit 6be3446 has been approved by Dylan-DPC

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 20, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jan 20, 2020
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.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 20, 2020
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.
bors added a commit that referenced this pull request Jan 20, 2020
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
@bors bors merged commit 6be3446 into rust-lang:master Jan 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants