Skip to content

Commit 9cd66be

Browse files
committed
docs: be less harsh in wording for Vec::from_raw_parts
In particular, be clear that it is sound to specify memory not originating from a previous `Vec` allocation. That is already suggested in other parts of the documentation about zero-alloc conversions to Box<[T]>. Incorporate a constraint from `slice::from_raw_parts` that was missing but needs to be fulfilled, since a `Vec` can be converted into a slice.
1 parent 42bd138 commit 9cd66be

File tree

1 file changed

+15
-5
lines changed

1 file changed

+15
-5
lines changed

library/alloc/src/vec/mod.rs

+15-5
Original file line numberDiff line numberDiff line change
@@ -490,8 +490,6 @@ impl<T> Vec<T> {
490490
/// This is highly unsafe, due to the number of invariants that aren't
491491
/// checked:
492492
///
493-
/// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>`
494-
/// (at least, it's highly likely to be incorrect if it wasn't).
495493
/// * `T` needs to have the same alignment as what `ptr` was allocated with.
496494
/// (`T` having a less strict alignment is not sufficient, the alignment really
497495
/// needs to be equal to satisfy the [`dealloc`] requirement that memory must be
@@ -500,6 +498,12 @@ impl<T> Vec<T> {
500498
/// to be the same size as the pointer was allocated with. (Because similar to
501499
/// alignment, [`dealloc`] must be called with the same layout `size`.)
502500
/// * `length` needs to be less than or equal to `capacity`.
501+
/// * `capacity` needs to be the capacity that the pointer was allocated with.
502+
/// * The allocated size in bytes must be no larger than `isize::MAX`.
503+
/// See the safety documentation of [`pointer::offset`].
504+
///
505+
/// To ensure these requirements are easily met, ensure `ptr` has previously
506+
/// been allocated via `Vec<T>`.
503507
///
504508
/// Violating these may cause problems like corrupting the allocator's
505509
/// internal data structures. For example it is normally **not** safe
@@ -648,14 +652,20 @@ impl<T, A: Allocator> Vec<T, A> {
648652
/// This is highly unsafe, due to the number of invariants that aren't
649653
/// checked:
650654
///
651-
/// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>`
652-
/// (at least, it's highly likely to be incorrect if it wasn't).
653-
/// * `T` needs to have the same size and alignment as what `ptr` was allocated with.
655+
/// * `T` needs to have the same alignment as what `ptr` was allocated with.
654656
/// (`T` having a less strict alignment is not sufficient, the alignment really
655657
/// needs to be equal to satisfy the [`dealloc`] requirement that memory must be
656658
/// allocated and deallocated with the same layout.)
659+
/// * The size of `T` times the `capacity` (ie. the allocated size in bytes) needs
660+
/// to be the same size as the pointer was allocated with. (Because similar to
661+
/// alignment, [`dealloc`] must be called with the same layout `size`.)
657662
/// * `length` needs to be less than or equal to `capacity`.
658663
/// * `capacity` needs to be the capacity that the pointer was allocated with.
664+
/// * The allocated size in bytes must be no larger than `isize::MAX`.
665+
/// See the safety documentation of [`pointer::offset`].
666+
///
667+
/// To ensure these requirements are easily met, ensure `ptr` has previously
668+
/// been allocated via `Vec<T>`.
659669
///
660670
/// Violating these may cause problems like corrupting the allocator's
661671
/// internal data structures. For example it is **not** safe

0 commit comments

Comments
 (0)