diff options
| author | Yuki Okushi <huyuumi.dev@gmail.com> | 2020-01-21 07:32:48 +0900 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-01-21 07:32:48 +0900 |
| commit | 32ecb6f1f2ad9a29c0d98bf9dd39a97467ce06e3 (patch) | |
| tree | 163b1b90cc71c136f348124ddf8a26c4b50b1663 /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 67b87c8ba861af77bee44e3375619151fac045bc (diff) | |
| parent | 6be3446f92b444cd6584c7948be9f7cf20ce5518 (diff) | |
| download | rust-32ecb6f1f2ad9a29c0d98bf9dd39a97467ce06e3.tar.gz rust-32ecb6f1f2ad9a29c0d98bf9dd39a97467ce06e3.zip | |
Rollup merge of #68381 - mjp41:master, r=Dylan-DPC
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.
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions