Skip to content

Commit 32ecb6f

Browse files
authored
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.
2 parents 67b87c8 + 6be3446 commit 32ecb6f

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

src/libcore/alloc.rs

+2-1
Original file line numberDiff line numberDiff line change
@@ -525,7 +525,8 @@ pub unsafe trait GlobalAlloc {
525525
/// The memory may or may not have been deallocated,
526526
/// and should be considered unusable (unless of course it was
527527
/// transferred back to the caller again via the return value of
528-
/// this method).
528+
/// this method). The new memory block is allocated with `layout`, but
529+
/// with the `size` updated to `new_size`.
529530
///
530531
/// If this method returns null, then ownership of the memory
531532
/// block has not been transferred to this allocator, and the

0 commit comments

Comments
 (0)