Primitive Type pointer1.0.0[−]
Expand description
Raw, unsafe pointers, *const T, and *mut T.
Working with raw pointers in Rust is uncommon, typically limited to a few patterns.
Raw pointers can be unaligned or null. However, when a raw pointer is
dereferenced (using the * operator), it must be non-null and aligned.
Storing through a raw pointer using *ptr = data calls drop on the old value, so
write must be used if the type has drop glue and memory is not already
initialized - otherwise drop would be called on the uninitialized memory.
Use the null and null_mut functions to create null pointers, and the
is_null method of the *const T and *mut T types to check for null.
The *const T and *mut T types also define the offset method, for
pointer math.
Common ways to create raw pointers
1. Coerce a reference (&T) or mutable reference (&mut T).
let my_num: i32 = 10;
let my_num_ptr: *const i32 = &my_num;
let mut my_speed: i32 = 88;
let my_speed_ptr: *mut i32 = &mut my_speed;RunTo get a pointer to a boxed value, dereference the box:
let my_num: Box<i32> = Box::new(10);
let my_num_ptr: *const i32 = &*my_num;
let mut my_speed: Box<i32> = Box::new(88);
let my_speed_ptr: *mut i32 = &mut *my_speed;RunThis does not take ownership of the original allocation and requires no resource management later, but you must not use the pointer after its lifetime.
2. Consume a box (Box<T>).
The into_raw function consumes a box and returns
the raw pointer. It doesn’t destroy T or deallocate any memory.
let my_speed: Box<i32> = Box::new(88);
let my_speed: *mut i32 = Box::into_raw(my_speed);
// By taking ownership of the original `Box<T>` though
// we are obligated to put it together later to be destroyed.
unsafe {
drop(Box::from_raw(my_speed));
}RunNote that here the call to drop is for clarity - it indicates
that we are done with the given value and it should be destroyed.
3. Create it using ptr::addr_of!
Instead of coercing a reference to a raw pointer, you can use the macros
ptr::addr_of! (for *const T) and ptr::addr_of_mut! (for *mut T).
These macros allow you to create raw pointers to fields to which you cannot
create a reference (without causing undefined behaviour), such as an
unaligned field. This might be necessary if packed structs or uninitialized
memory is involved.
#[derive(Debug, Default, Copy, Clone)]
#[repr(C, packed)]
struct S {
aligned: u8,
unaligned: u32,
}
let s = S::default();
let p = std::ptr::addr_of!(s.unaligned); // not allowed with coercionRun4. Get it from C.
extern crate libc;
use std::mem;
unsafe {
let my_num: *mut i32 = libc::malloc(mem::size_of::<i32>()) as *mut i32;
if my_num.is_null() {
panic!("failed to allocate memory");
}
libc::free(my_num as *mut libc::c_void);
}RunUsually you wouldn’t literally use malloc and free from Rust,
but C APIs hand out a lot of pointers generally, so are a common source
of raw pointers in Rust.
Implementations
Returns true if the pointer is null.
Note that unsized types have many possible null pointers, as only the raw data pointer is considered, not their length, vtable, etc. Therefore, two pointers that are null may still not compare equal to each other.
Behavior during const evaluation
When this function is used during const evaluation, it may return false for pointers
that turn out to be null at runtime. Specifically, when a pointer to some memory
is offset beyond its bounds in such a way that the resulting pointer is null,
the function will still return false. There is no way for CTFE to know
the absolute position of that memory, so we cannot tell if the pointer is
null or not.
Examples
Basic usage:
let s: &str = "Follow the rabbit";
let ptr: *const u8 = s.as_ptr();
assert!(!ptr.is_null());RunCasts to a pointer of another type.
Decompose a (possibly wide) pointer into its address and metadata components.
The pointer can be later reconstructed with from_raw_parts.
Returns None if the pointer is null, or else returns a shared reference to
the value wrapped in Some. If the value may be uninitialized, as_uninit_ref
must be used instead.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be properly aligned.
-
It must be “dereferencable” in the sense defined in the module documentation.
-
The pointer must point to an initialized instance of
T. -
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get mutated (except insideUnsafeCell).
This applies even if the result of this method is unused! (The part about being initialized is not yet fully decided, but until it is, the only safe approach is to ensure that they are indeed initialized.)
Examples
Basic usage:
let ptr: *const u8 = &10u8 as *const u8;
unsafe {
if let Some(val_back) = ptr.as_ref() {
println!("We got back the value: {}!", val_back);
}
}RunNull-unchecked version
If you are sure the pointer can never be null and are looking for some kind of
as_ref_unchecked that returns the &T instead of Option<&T>, know that you can
dereference the pointer directly.
let ptr: *const u8 = &10u8 as *const u8;
unsafe {
let val_back = &*ptr;
println!("We got back the value: {}!", val_back);
}RunReturns None if the pointer is null, or else returns a shared reference to
the value wrapped in Some. In contrast to as_ref, this does not require
that the value has to be initialized.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be properly aligned.
-
It must be “dereferencable” in the sense defined in the module documentation.
-
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get mutated (except insideUnsafeCell).
This applies even if the result of this method is unused!
Examples
Basic usage:
#![feature(ptr_as_uninit)]
let ptr: *const u8 = &10u8 as *const u8;
unsafe {
if let Some(val_back) = ptr.as_uninit_ref() {
println!("We got back the value: {}!", val_back.assume_init());
}
}RunCalculates the offset from a pointer.
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
-
The computed offset, in bytes, cannot overflow an
isize. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum, in bytes must fit in a usize.
The compiler and standard library generally tries to ensure allocations
never reach a size where an offset is a concern. For instance, Vec
and Box ensure they never allocate more than isize::MAX bytes, so
vec.as_ptr().add(vec.len()) is always safe.
Most platforms fundamentally can’t even construct such an allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_offset instead if these constraints are
difficult to satisfy. The only advantage of this method is that it
enables more aggressive compiler optimizations.
Examples
Basic usage:
let s: &str = "123";
let ptr: *const u8 = s.as_ptr();
unsafe {
println!("{}", *ptr.offset(1) as char);
println!("{}", *ptr.offset(2) as char);
}RunCalculates the offset from a pointer using wrapping arithmetic.
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
This operation itself is always safe, but using the resulting pointer is not.
The resulting pointer “remembers” the allocated object that self points to; it must not
be used to read or write other allocated objects.
In other words, let z = x.wrapping_offset((y as isize) - (x as isize)) does not make z
the same as y even if we assume T has size 1 and there is no overflow: z is still
attached to the object x is attached to, and dereferencing it is Undefined Behavior unless
x and y point into the same allocated object.
Compared to offset, this method basically delays the requirement of staying within the
same allocated object: offset is immediate Undefined Behavior when crossing object
boundaries; wrapping_offset produces a pointer but still leads to Undefined Behavior if a
pointer is dereferenced when it is out-of-bounds of the object it is attached to. offset
can be optimized better and is thus preferable in performance-sensitive code.
The delayed check only considers the value of the pointer that was dereferenced, not the
intermediate values used during the computation of the final result. For example,
x.wrapping_offset(o).wrapping_offset(o.wrapping_neg()) is always the same as x. In other
words, leaving the allocated object and then re-entering it later is permitted.
Examples
Basic usage:
// Iterate using a raw pointer in increments of two elements
let data = [1u8, 2, 3, 4, 5];
let mut ptr: *const u8 = data.as_ptr();
let step = 2;
let end_rounded_up = ptr.wrapping_offset(6);
// This loop prints "1, 3, 5, "
while ptr != end_rounded_up {
unsafe {
print!("{}, ", *ptr);
}
ptr = ptr.wrapping_offset(step);
}RunCalculates the distance between two pointers. The returned value is in
units of T: the distance in bytes is divided by mem::size_of::<T>().
This function is the inverse of offset.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and other pointer must be either in bounds or one byte past the end of the same allocated object.
-
Both pointers must be derived from a pointer to the same object. (See below for an example.)
-
The distance between the pointers, in bytes, must be an exact multiple of the size of
T. -
The distance between the pointers, in bytes, cannot overflow an
isize. -
The distance being in bounds cannot rely on “wrapping around” the address space.
Rust types are never larger than isize::MAX and Rust allocations never wrap around the
address space, so two pointers within some value of any Rust type T will always satisfy
the last two conditions. The standard library also generally ensures that allocations
never reach a size where an offset is a concern. For instance, Vec and Box ensure they
never allocate more than isize::MAX bytes, so ptr_into_vec.offset_from(vec.as_ptr())
always satisfies the last two conditions.
Most platforms fundamentally can’t even construct such a large allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
(Note that offset and add also have a similar limitation and hence cannot be used on
such large allocations either.)
Panics
This function panics if T is a Zero-Sized Type (“ZST”).
Examples
Basic usage:
let a = [0; 5];
let ptr1: *const i32 = &a[1];
let ptr2: *const i32 = &a[3];
unsafe {
assert_eq!(ptr2.offset_from(ptr1), 2);
assert_eq!(ptr1.offset_from(ptr2), -2);
assert_eq!(ptr1.offset(2), ptr2);
assert_eq!(ptr2.offset(-2), ptr1);
}RunIncorrect usage:
let ptr1 = Box::into_raw(Box::new(0u8)) as *const u8;
let ptr2 = Box::into_raw(Box::new(1u8)) as *const u8;
let diff = (ptr2 as isize).wrapping_sub(ptr1 as isize);
// Make ptr2_other an "alias" of ptr2, but derived from ptr1.
let ptr2_other = (ptr1 as *const u8).wrapping_offset(diff);
assert_eq!(ptr2 as usize, ptr2_other as usize);
// Since ptr2_other and ptr2 are derived from pointers to different objects,
// computing their offset is undefined behavior, even though
// they point to the same address!
unsafe {
let zero = ptr2_other.offset_from(ptr2); // Undefined Behavior
}RunReturns whether two pointers are guaranteed to be equal.
At runtime this function behaves like self == other.
However, in some contexts (e.g., compile-time evaluation),
it is not always possible to determine equality of two pointers, so this function may
spuriously return false for pointers that later actually turn out to be equal.
But when it returns true, the pointers are guaranteed to be equal.
This function is the mirror of guaranteed_ne, but not its inverse. There are pointer
comparisons for which both functions return false.
The return value may change depending on the compiler version and unsafe code might not
rely on the result of this function for soundness. It is suggested to only use this function
for performance optimizations where spurious false return values by this function do not
affect the outcome, but just the performance.
The consequences of using this method to make runtime and compile-time code behave
differently have not been explored. This method should not be used to introduce such
differences, and it should also not be stabilized before we have a better understanding
of this issue.
Returns whether two pointers are guaranteed to be unequal.
At runtime this function behaves like self != other.
However, in some contexts (e.g., compile-time evaluation),
it is not always possible to determine the inequality of two pointers, so this function may
spuriously return false for pointers that later actually turn out to be unequal.
But when it returns true, the pointers are guaranteed to be unequal.
This function is the mirror of guaranteed_eq, but not its inverse. There are pointer
comparisons for which both functions return false.
The return value may change depending on the compiler version and unsafe code might not
rely on the result of this function for soundness. It is suggested to only use this function
for performance optimizations where spurious false return values by this function do not
affect the outcome, but just the performance.
The consequences of using this method to make runtime and compile-time code behave
differently have not been explored. This method should not be used to introduce such
differences, and it should also not be stabilized before we have a better understanding
of this issue.
Calculates the offset from a pointer (convenience for .offset(count as isize)).
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
-
The computed offset, in bytes, cannot overflow an
isize. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum must fit in a
usize.
The compiler and standard library generally tries to ensure allocations
never reach a size where an offset is a concern. For instance, Vec
and Box ensure they never allocate more than isize::MAX bytes, so
vec.as_ptr().add(vec.len()) is always safe.
Most platforms fundamentally can’t even construct such an allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_add instead if these constraints are
difficult to satisfy. The only advantage of this method is that it
enables more aggressive compiler optimizations.
Examples
Basic usage:
let s: &str = "123";
let ptr: *const u8 = s.as_ptr();
unsafe {
println!("{}", *ptr.add(1) as char);
println!("{}", *ptr.add(2) as char);
}RunCalculates the offset from a pointer (convenience for
.offset((count as isize).wrapping_neg())).
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
-
The computed offset cannot exceed
isize::MAXbytes. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum must fit in a usize.
The compiler and standard library generally tries to ensure allocations
never reach a size where an offset is a concern. For instance, Vec
and Box ensure they never allocate more than isize::MAX bytes, so
vec.as_ptr().add(vec.len()).sub(vec.len()) is always safe.
Most platforms fundamentally can’t even construct such an allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_sub instead if these constraints are
difficult to satisfy. The only advantage of this method is that it
enables more aggressive compiler optimizations.
Examples
Basic usage:
let s: &str = "123";
unsafe {
let end: *const u8 = s.as_ptr().add(3);
println!("{}", *end.sub(1) as char);
println!("{}", *end.sub(2) as char);
}RunCalculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset(count as isize))
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
This operation itself is always safe, but using the resulting pointer is not.
The resulting pointer “remembers” the allocated object that self points to; it must not
be used to read or write other allocated objects.
In other words, let z = x.wrapping_add((y as usize) - (x as usize)) does not make z
the same as y even if we assume T has size 1 and there is no overflow: z is still
attached to the object x is attached to, and dereferencing it is Undefined Behavior unless
x and y point into the same allocated object.
Compared to add, this method basically delays the requirement of staying within the
same allocated object: add is immediate Undefined Behavior when crossing object
boundaries; wrapping_add produces a pointer but still leads to Undefined Behavior if a
pointer is dereferenced when it is out-of-bounds of the object it is attached to. add
can be optimized better and is thus preferable in performance-sensitive code.
The delayed check only considers the value of the pointer that was dereferenced, not the
intermediate values used during the computation of the final result. For example,
x.wrapping_add(o).wrapping_sub(o) is always the same as x. In other words, leaving the
allocated object and then re-entering it later is permitted.
Examples
Basic usage:
// Iterate using a raw pointer in increments of two elements
let data = [1u8, 2, 3, 4, 5];
let mut ptr: *const u8 = data.as_ptr();
let step = 2;
let end_rounded_up = ptr.wrapping_add(6);
// This loop prints "1, 3, 5, "
while ptr != end_rounded_up {
unsafe {
print!("{}, ", *ptr);
}
ptr = ptr.wrapping_add(step);
}RunCalculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset((count as isize).wrapping_neg()))
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
This operation itself is always safe, but using the resulting pointer is not.
The resulting pointer “remembers” the allocated object that self points to; it must not
be used to read or write other allocated objects.
In other words, let z = x.wrapping_sub((x as usize) - (y as usize)) does not make z
the same as y even if we assume T has size 1 and there is no overflow: z is still
attached to the object x is attached to, and dereferencing it is Undefined Behavior unless
x and y point into the same allocated object.
Compared to sub, this method basically delays the requirement of staying within the
same allocated object: sub is immediate Undefined Behavior when crossing object
boundaries; wrapping_sub produces a pointer but still leads to Undefined Behavior if a
pointer is dereferenced when it is out-of-bounds of the object it is attached to. sub
can be optimized better and is thus preferable in performance-sensitive code.
The delayed check only considers the value of the pointer that was dereferenced, not the
intermediate values used during the computation of the final result. For example,
x.wrapping_add(o).wrapping_sub(o) is always the same as x. In other words, leaving the
allocated object and then re-entering it later is permitted.
Examples
Basic usage:
// Iterate using a raw pointer in increments of two elements (backwards)
let data = [1u8, 2, 3, 4, 5];
let mut ptr: *const u8 = data.as_ptr();
let start_rounded_down = ptr.wrapping_sub(2);
ptr = ptr.wrapping_add(4);
let step = 2;
// This loop prints "5, 3, 1, "
while ptr != start_rounded_down {
unsafe {
print!("{}, ", *ptr);
}
ptr = ptr.wrapping_sub(step);
}RunSets the pointer value to ptr.
In case self is a (fat) pointer to an unsized type, this operation
will only affect the pointer part, whereas for (thin) pointers to
sized types, this has the same effect as a simple assignment.
The resulting pointer will have provenance of val, i.e., for a fat
pointer, this operation is semantically the same as creating a new
fat pointer with the data pointer value of val but the metadata of
self.
Examples
This function is primarily useful for allowing byte-wise pointer arithmetic on potentially fat pointers:
#![feature(set_ptr_value)]
let arr: [i32; 3] = [1, 2, 3];
let mut ptr = arr.as_ptr() as *const dyn Debug;
let thin = ptr as *const u8;
unsafe {
ptr = ptr.set_ptr_value(thin.add(8));
println!("{:?}", &*ptr); // will print "3"
}RunReads the value from self without moving it. This leaves the
memory in self unchanged.
See ptr::read for safety concerns and examples.
Performs a volatile read of the value from self without moving it. This
leaves the memory in self unchanged.
Volatile operations are intended to act on I/O memory, and are guaranteed to not be elided or reordered by the compiler across other volatile operations.
See ptr::read_volatile for safety concerns and examples.
Reads the value from self without moving it. This leaves the
memory in self unchanged.
Unlike read, the pointer may be unaligned.
See ptr::read_unaligned for safety concerns and examples.
Copies count * size_of<T> bytes from self to dest. The source
and destination may not overlap.
NOTE: this has the same argument order as ptr::copy_nonoverlapping.
See ptr::copy_nonoverlapping for safety concerns and examples.
Computes the offset that needs to be applied to the pointer in order to make it aligned to
align.
If it is not possible to align the pointer, the implementation returns
usize::MAX. It is permissible for the implementation to always
return usize::MAX. Only your algorithm’s performance can depend
on getting a usable offset here, not its correctness.
The offset is expressed in number of T elements, and not bytes. The value returned can be
used with the wrapping_add method.
There are no guarantees whatsoever that offsetting the pointer will not overflow or go beyond the allocation that the pointer points into. It is up to the caller to ensure that the returned offset is correct in all terms other than alignment.
Panics
The function panics if align is not a power-of-two.
Examples
Accessing adjacent u8 as u16
let x = [5u8, 6u8, 7u8, 8u8, 9u8];
let ptr = x.as_ptr().add(n) as *const u8;
let offset = ptr.align_offset(align_of::<u16>());
if offset < x.len() - n - 1 {
let u16_ptr = ptr.add(offset) as *const u16;
assert_ne!(*u16_ptr, 500);
} else {
// while the pointer can be aligned via `offset`, it would point
// outside the allocation
}RunReturns true if the pointer is null.
Note that unsized types have many possible null pointers, as only the raw data pointer is considered, not their length, vtable, etc. Therefore, two pointers that are null may still not compare equal to each other.
Behavior during const evaluation
When this function is used during const evaluation, it may return false for pointers
that turn out to be null at runtime. Specifically, when a pointer to some memory
is offset beyond its bounds in such a way that the resulting pointer is null,
the function will still return false. There is no way for CTFE to know
the absolute position of that memory, so we cannot tell if the pointer is
null or not.
Examples
Basic usage:
let mut s = [1, 2, 3];
let ptr: *mut u32 = s.as_mut_ptr();
assert!(!ptr.is_null());RunDecompose a (possibly wide) pointer into its address and metadata components.
The pointer can be later reconstructed with from_raw_parts_mut.
Returns None if the pointer is null, or else returns a shared reference to
the value wrapped in Some. If the value may be uninitialized, as_uninit_ref
must be used instead.
For the mutable counterpart see as_mut.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be properly aligned.
-
It must be “dereferencable” in the sense defined in the module documentation.
-
The pointer must point to an initialized instance of
T. -
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get mutated (except insideUnsafeCell).
This applies even if the result of this method is unused! (The part about being initialized is not yet fully decided, but until it is, the only safe approach is to ensure that they are indeed initialized.)
Examples
Basic usage:
let ptr: *mut u8 = &mut 10u8 as *mut u8;
unsafe {
if let Some(val_back) = ptr.as_ref() {
println!("We got back the value: {}!", val_back);
}
}RunNull-unchecked version
If you are sure the pointer can never be null and are looking for some kind of
as_ref_unchecked that returns the &T instead of Option<&T>, know that you can
dereference the pointer directly.
let ptr: *mut u8 = &mut 10u8 as *mut u8;
unsafe {
let val_back = &*ptr;
println!("We got back the value: {}!", val_back);
}RunReturns None if the pointer is null, or else returns a shared reference to
the value wrapped in Some. In contrast to as_ref, this does not require
that the value has to be initialized.
For the mutable counterpart see as_uninit_mut.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be properly aligned.
-
It must be “dereferencable” in the sense defined in the module documentation.
-
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get mutated (except insideUnsafeCell).
This applies even if the result of this method is unused!
Examples
Basic usage:
#![feature(ptr_as_uninit)]
let ptr: *mut u8 = &mut 10u8 as *mut u8;
unsafe {
if let Some(val_back) = ptr.as_uninit_ref() {
println!("We got back the value: {}!", val_back.assume_init());
}
}RunCalculates the offset from a pointer.
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
-
The computed offset, in bytes, cannot overflow an
isize. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum, in bytes must fit in a usize.
The compiler and standard library generally tries to ensure allocations
never reach a size where an offset is a concern. For instance, Vec
and Box ensure they never allocate more than isize::MAX bytes, so
vec.as_ptr().add(vec.len()) is always safe.
Most platforms fundamentally can’t even construct such an allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_offset instead if these constraints are
difficult to satisfy. The only advantage of this method is that it
enables more aggressive compiler optimizations.
Examples
Basic usage:
let mut s = [1, 2, 3];
let ptr: *mut u32 = s.as_mut_ptr();
unsafe {
println!("{}", *ptr.offset(1));
println!("{}", *ptr.offset(2));
}RunCalculates the offset from a pointer using wrapping arithmetic.
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
This operation itself is always safe, but using the resulting pointer is not.
The resulting pointer “remembers” the allocated object that self points to; it must not
be used to read or write other allocated objects.
In other words, let z = x.wrapping_offset((y as isize) - (x as isize)) does not make z
the same as y even if we assume T has size 1 and there is no overflow: z is still
attached to the object x is attached to, and dereferencing it is Undefined Behavior unless
x and y point into the same allocated object.
Compared to offset, this method basically delays the requirement of staying within the
same allocated object: offset is immediate Undefined Behavior when crossing object
boundaries; wrapping_offset produces a pointer but still leads to Undefined Behavior if a
pointer is dereferenced when it is out-of-bounds of the object it is attached to. offset
can be optimized better and is thus preferable in performance-sensitive code.
The delayed check only considers the value of the pointer that was dereferenced, not the
intermediate values used during the computation of the final result. For example,
x.wrapping_offset(o).wrapping_offset(o.wrapping_neg()) is always the same as x. In other
words, leaving the allocated object and then re-entering it later is permitted.
Examples
Basic usage:
// Iterate using a raw pointer in increments of two elements
let mut data = [1u8, 2, 3, 4, 5];
let mut ptr: *mut u8 = data.as_mut_ptr();
let step = 2;
let end_rounded_up = ptr.wrapping_offset(6);
while ptr != end_rounded_up {
unsafe {
*ptr = 0;
}
ptr = ptr.wrapping_offset(step);
}
assert_eq!(&data, &[0, 2, 0, 4, 0]);RunReturns None if the pointer is null, or else returns a unique reference to
the value wrapped in Some. If the value may be uninitialized, as_uninit_mut
must be used instead.
For the shared counterpart see as_ref.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be properly aligned.
-
It must be “dereferencable” in the sense defined in the module documentation.
-
The pointer must point to an initialized instance of
T. -
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get accessed (read or written) through any other pointer.
This applies even if the result of this method is unused! (The part about being initialized is not yet fully decided, but until it is, the only safe approach is to ensure that they are indeed initialized.)
Examples
Basic usage:
let mut s = [1, 2, 3];
let ptr: *mut u32 = s.as_mut_ptr();
let first_value = unsafe { ptr.as_mut().unwrap() };
*first_value = 4;
println!("{:?}", s); // It'll print: "[4, 2, 3]".RunNull-unchecked version
If you are sure the pointer can never be null and are looking for some kind of
as_mut_unchecked that returns the &mut T instead of Option<&mut T>, know that
you can dereference the pointer directly.
let mut s = [1, 2, 3];
let ptr: *mut u32 = s.as_mut_ptr();
let first_value = unsafe { &mut *ptr };
*first_value = 4;
println!("{:?}", s); // It'll print: "[4, 2, 3]".RunReturns None if the pointer is null, or else returns a unique reference to
the value wrapped in Some. In contrast to as_mut, this does not require
that the value has to be initialized.
For the shared counterpart see as_uninit_ref.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be properly aligned.
-
It must be “dereferencable” in the sense defined in the module documentation.
-
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get accessed (read or written) through any other pointer.
This applies even if the result of this method is unused!
Returns whether two pointers are guaranteed to be equal.
At runtime this function behaves like self == other.
However, in some contexts (e.g., compile-time evaluation),
it is not always possible to determine equality of two pointers, so this function may
spuriously return false for pointers that later actually turn out to be equal.
But when it returns true, the pointers are guaranteed to be equal.
This function is the mirror of guaranteed_ne, but not its inverse. There are pointer
comparisons for which both functions return false.
The return value may change depending on the compiler version and unsafe code might not
rely on the result of this function for soundness. It is suggested to only use this function
for performance optimizations where spurious false return values by this function do not
affect the outcome, but just the performance.
The consequences of using this method to make runtime and compile-time code behave
differently have not been explored. This method should not be used to introduce such
differences, and it should also not be stabilized before we have a better understanding
of this issue.
Returns whether two pointers are guaranteed to be unequal.
At runtime this function behaves like self != other.
However, in some contexts (e.g., compile-time evaluation),
it is not always possible to determine the inequality of two pointers, so this function may
spuriously return false for pointers that later actually turn out to be unequal.
But when it returns true, the pointers are guaranteed to be unequal.
This function is the mirror of guaranteed_eq, but not its inverse. There are pointer
comparisons for which both functions return false.
The return value may change depending on the compiler version and unsafe code might not
rely on the result of this function for soundness. It is suggested to only use this function
for performance optimizations where spurious false return values by this function do not
affect the outcome, but just the performance.
The consequences of using this method to make runtime and compile-time code behave
differently have not been explored. This method should not be used to introduce such
differences, and it should also not be stabilized before we have a better understanding
of this issue.
Calculates the distance between two pointers. The returned value is in
units of T: the distance in bytes is divided by mem::size_of::<T>().
This function is the inverse of offset.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and other pointer must be either in bounds or one byte past the end of the same allocated object.
-
Both pointers must be derived from a pointer to the same object. (See below for an example.)
-
The distance between the pointers, in bytes, must be an exact multiple of the size of
T. -
The distance between the pointers, in bytes, cannot overflow an
isize. -
The distance being in bounds cannot rely on “wrapping around” the address space.
Rust types are never larger than isize::MAX and Rust allocations never wrap around the
address space, so two pointers within some value of any Rust type T will always satisfy
the last two conditions. The standard library also generally ensures that allocations
never reach a size where an offset is a concern. For instance, Vec and Box ensure they
never allocate more than isize::MAX bytes, so ptr_into_vec.offset_from(vec.as_ptr())
always satisfies the last two conditions.
Most platforms fundamentally can’t even construct such a large allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
(Note that offset and add also have a similar limitation and hence cannot be used on
such large allocations either.)
Panics
This function panics if T is a Zero-Sized Type (“ZST”).
Examples
Basic usage:
let mut a = [0; 5];
let ptr1: *mut i32 = &mut a[1];
let ptr2: *mut i32 = &mut a[3];
unsafe {
assert_eq!(ptr2.offset_from(ptr1), 2);
assert_eq!(ptr1.offset_from(ptr2), -2);
assert_eq!(ptr1.offset(2), ptr2);
assert_eq!(ptr2.offset(-2), ptr1);
}RunIncorrect usage:
let ptr1 = Box::into_raw(Box::new(0u8));
let ptr2 = Box::into_raw(Box::new(1u8));
let diff = (ptr2 as isize).wrapping_sub(ptr1 as isize);
// Make ptr2_other an "alias" of ptr2, but derived from ptr1.
let ptr2_other = (ptr1 as *mut u8).wrapping_offset(diff);
assert_eq!(ptr2 as usize, ptr2_other as usize);
// Since ptr2_other and ptr2 are derived from pointers to different objects,
// computing their offset is undefined behavior, even though
// they point to the same address!
unsafe {
let zero = ptr2_other.offset_from(ptr2); // Undefined Behavior
}RunCalculates the offset from a pointer (convenience for .offset(count as isize)).
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
-
The computed offset, in bytes, cannot overflow an
isize. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum must fit in a
usize.
The compiler and standard library generally tries to ensure allocations
never reach a size where an offset is a concern. For instance, Vec
and Box ensure they never allocate more than isize::MAX bytes, so
vec.as_ptr().add(vec.len()) is always safe.
Most platforms fundamentally can’t even construct such an allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_add instead if these constraints are
difficult to satisfy. The only advantage of this method is that it
enables more aggressive compiler optimizations.
Examples
Basic usage:
let s: &str = "123";
let ptr: *const u8 = s.as_ptr();
unsafe {
println!("{}", *ptr.add(1) as char);
println!("{}", *ptr.add(2) as char);
}RunCalculates the offset from a pointer (convenience for
.offset((count as isize).wrapping_neg())).
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
-
The computed offset cannot exceed
isize::MAXbytes. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum must fit in a usize.
The compiler and standard library generally tries to ensure allocations
never reach a size where an offset is a concern. For instance, Vec
and Box ensure they never allocate more than isize::MAX bytes, so
vec.as_ptr().add(vec.len()).sub(vec.len()) is always safe.
Most platforms fundamentally can’t even construct such an allocation.
For instance, no known 64-bit platform can ever serve a request
for 263 bytes due to page-table limitations or splitting the address space.
However, some 32-bit and 16-bit platforms may successfully serve a request for
more than isize::MAX bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_sub instead if these constraints are
difficult to satisfy. The only advantage of this method is that it
enables more aggressive compiler optimizations.
Examples
Basic usage:
let s: &str = "123";
unsafe {
let end: *const u8 = s.as_ptr().add(3);
println!("{}", *end.sub(1) as char);
println!("{}", *end.sub(2) as char);
}RunCalculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset(count as isize))
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
This operation itself is always safe, but using the resulting pointer is not.
The resulting pointer “remembers” the allocated object that self points to; it must not
be used to read or write other allocated objects.
In other words, let z = x.wrapping_add((y as usize) - (x as usize)) does not make z
the same as y even if we assume T has size 1 and there is no overflow: z is still
attached to the object x is attached to, and dereferencing it is Undefined Behavior unless
x and y point into the same allocated object.
Compared to add, this method basically delays the requirement of staying within the
same allocated object: add is immediate Undefined Behavior when crossing object
boundaries; wrapping_add produces a pointer but still leads to Undefined Behavior if a
pointer is dereferenced when it is out-of-bounds of the object it is attached to. add
can be optimized better and is thus preferable in performance-sensitive code.
The delayed check only considers the value of the pointer that was dereferenced, not the
intermediate values used during the computation of the final result. For example,
x.wrapping_add(o).wrapping_sub(o) is always the same as x. In other words, leaving the
allocated object and then re-entering it later is permitted.
Examples
Basic usage:
// Iterate using a raw pointer in increments of two elements
let data = [1u8, 2, 3, 4, 5];
let mut ptr: *const u8 = data.as_ptr();
let step = 2;
let end_rounded_up = ptr.wrapping_add(6);
// This loop prints "1, 3, 5, "
while ptr != end_rounded_up {
unsafe {
print!("{}, ", *ptr);
}
ptr = ptr.wrapping_add(step);
}RunCalculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset((count as isize).wrapping_neg()))
count is in units of T; e.g., a count of 3 represents a pointer
offset of 3 * size_of::<T>() bytes.
Safety
This operation itself is always safe, but using the resulting pointer is not.
The resulting pointer “remembers” the allocated object that self points to; it must not
be used to read or write other allocated objects.
In other words, let z = x.wrapping_sub((x as usize) - (y as usize)) does not make z
the same as y even if we assume T has size 1 and there is no overflow: z is still
attached to the object x is attached to, and dereferencing it is Undefined Behavior unless
x and y point into the same allocated object.
Compared to sub, this method basically delays the requirement of staying within the
same allocated object: sub is immediate Undefined Behavior when crossing object
boundaries; wrapping_sub produces a pointer but still leads to Undefined Behavior if a
pointer is dereferenced when it is out-of-bounds of the object it is attached to. sub
can be optimized better and is thus preferable in performance-sensitive code.
The delayed check only considers the value of the pointer that was dereferenced, not the
intermediate values used during the computation of the final result. For example,
x.wrapping_add(o).wrapping_sub(o) is always the same as x. In other words, leaving the
allocated object and then re-entering it later is permitted.
Examples
Basic usage:
// Iterate using a raw pointer in increments of two elements (backwards)
let data = [1u8, 2, 3, 4, 5];
let mut ptr: *const u8 = data.as_ptr();
let start_rounded_down = ptr.wrapping_sub(2);
ptr = ptr.wrapping_add(4);
let step = 2;
// This loop prints "5, 3, 1, "
while ptr != start_rounded_down {
unsafe {
print!("{}, ", *ptr);
}
ptr = ptr.wrapping_sub(step);
}RunSets the pointer value to ptr.
In case self is a (fat) pointer to an unsized type, this operation
will only affect the pointer part, whereas for (thin) pointers to
sized types, this has the same effect as a simple assignment.
The resulting pointer will have provenance of val, i.e., for a fat
pointer, this operation is semantically the same as creating a new
fat pointer with the data pointer value of val but the metadata of
self.
Examples
This function is primarily useful for allowing byte-wise pointer arithmetic on potentially fat pointers:
#![feature(set_ptr_value)]
let mut arr: [i32; 3] = [1, 2, 3];
let mut ptr = arr.as_mut_ptr() as *mut dyn Debug;
let thin = ptr as *mut u8;
unsafe {
ptr = ptr.set_ptr_value(thin.add(8));
println!("{:?}", &*ptr); // will print "3"
}RunReads the value from self without moving it. This leaves the
memory in self unchanged.
See ptr::read for safety concerns and examples.
Performs a volatile read of the value from self without moving it. This
leaves the memory in self unchanged.
Volatile operations are intended to act on I/O memory, and are guaranteed to not be elided or reordered by the compiler across other volatile operations.
See ptr::read_volatile for safety concerns and examples.
Reads the value from self without moving it. This leaves the
memory in self unchanged.
Unlike read, the pointer may be unaligned.
See ptr::read_unaligned for safety concerns and examples.
Copies count * size_of<T> bytes from self to dest. The source
and destination may not overlap.
NOTE: this has the same argument order as ptr::copy_nonoverlapping.
See ptr::copy_nonoverlapping for safety concerns and examples.
pub unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize)
pub unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize)
Copies count * size_of<T> bytes from src to self. The source
and destination may not overlap.
NOTE: this has the opposite argument order of ptr::copy_nonoverlapping.
See ptr::copy_nonoverlapping for safety concerns and examples.
Executes the destructor (if any) of the pointed-to value.
See ptr::drop_in_place for safety concerns and examples.
Overwrites a memory location with the given value without reading or dropping the old value.
See ptr::write for safety concerns and examples.
Invokes memset on the specified pointer, setting count * size_of::<T>()
bytes of memory starting at self to val.
See ptr::write_bytes for safety concerns and examples.
Performs a volatile write of a memory location with the given value without reading or dropping the old value.
Volatile operations are intended to act on I/O memory, and are guaranteed to not be elided or reordered by the compiler across other volatile operations.
See ptr::write_volatile for safety concerns and examples.
Overwrites a memory location with the given value without reading or dropping the old value.
Unlike write, the pointer may be unaligned.
See ptr::write_unaligned for safety concerns and examples.
Replaces the value at self with src, returning the old
value, without dropping either.
See ptr::replace for safety concerns and examples.
Swaps the values at two mutable locations of the same type, without
deinitializing either. They may overlap, unlike mem::swap which is
otherwise equivalent.
See ptr::swap for safety concerns and examples.
Computes the offset that needs to be applied to the pointer in order to make it aligned to
align.
If it is not possible to align the pointer, the implementation returns
usize::MAX. It is permissible for the implementation to always
return usize::MAX. Only your algorithm’s performance can depend
on getting a usable offset here, not its correctness.
The offset is expressed in number of T elements, and not bytes. The value returned can be
used with the wrapping_add method.
There are no guarantees whatsoever that offsetting the pointer will not overflow or go beyond the allocation that the pointer points into. It is up to the caller to ensure that the returned offset is correct in all terms other than alignment.
Panics
The function panics if align is not a power-of-two.
Examples
Accessing adjacent u8 as u16
let x = [5u8, 6u8, 7u8, 8u8, 9u8];
let ptr = x.as_ptr().add(n) as *const u8;
let offset = ptr.align_offset(align_of::<u16>());
if offset < x.len() - n - 1 {
let u16_ptr = ptr.add(offset) as *const u16;
assert_ne!(*u16_ptr, 500);
} else {
// while the pointer can be aligned via `offset`, it would point
// outside the allocation
}RunReturns the length of a raw slice.
The returned value is the number of elements, not the number of bytes.
This function is safe, even when the raw slice cannot be cast to a slice reference because the pointer is null or unaligned.
Examples
#![feature(slice_ptr_len)]
use std::ptr;
let slice: *const [i8] = ptr::slice_from_raw_parts(ptr::null(), 3);
assert_eq!(slice.len(), 3);Runpub unsafe fn get_unchecked<I>(
self,
index: I
) -> *const <I as SliceIndex<[T]>>::Output where
I: SliceIndex<[T]>,
pub unsafe fn get_unchecked<I>(
self,
index: I
) -> *const <I as SliceIndex<[T]>>::Output where
I: SliceIndex<[T]>,
Returns a raw pointer to an element or subslice, without doing bounds checking.
Calling this method with an out-of-bounds index or when self is not dereferencable
is undefined behavior even if the resulting pointer is not used.
Examples
#![feature(slice_ptr_get)]
let x = &[1, 2, 4] as *const [i32];
unsafe {
assert_eq!(x.get_unchecked(1), x.as_ptr().add(1));
}RunReturns None if the pointer is null, or else returns a shared slice to
the value wrapped in Some. In contrast to as_ref, this does not require
that the value has to be initialized.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be valid for reads for
ptr.len() * mem::size_of::<T>()many bytes, and it must be properly aligned. This means in particular:-
The entire memory range of this slice must be contained within a single allocated object! Slices can never span across multiple allocated objects.
-
The pointer must be aligned even for zero-length slices. One reason for this is that enum layout optimizations may rely on references (including slices of any length) being aligned and non-null to distinguish them from other data. You can obtain a pointer that is usable as
datafor zero-length slices usingNonNull::dangling().
-
-
The total size
ptr.len() * mem::size_of::<T>()of the slice must be no larger thanisize::MAX. See the safety documentation ofpointer::offset. -
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get mutated (except insideUnsafeCell).
This applies even if the result of this method is unused!
See also slice::from_raw_parts.
Returns the length of a raw slice.
The returned value is the number of elements, not the number of bytes.
This function is safe, even when the raw slice cannot be cast to a slice reference because the pointer is null or unaligned.
Examples
#![feature(slice_ptr_len)]
use std::ptr;
let slice: *mut [i8] = ptr::slice_from_raw_parts_mut(ptr::null_mut(), 3);
assert_eq!(slice.len(), 3);Runpub unsafe fn get_unchecked_mut<I>(
self,
index: I
) -> *mut <I as SliceIndex<[T]>>::Output where
I: SliceIndex<[T]>,
pub unsafe fn get_unchecked_mut<I>(
self,
index: I
) -> *mut <I as SliceIndex<[T]>>::Output where
I: SliceIndex<[T]>,
Returns a raw pointer to an element or subslice, without doing bounds checking.
Calling this method with an out-of-bounds index or when self is not dereferencable
is undefined behavior even if the resulting pointer is not used.
Examples
#![feature(slice_ptr_get)]
let x = &mut [1, 2, 4] as *mut [i32];
unsafe {
assert_eq!(x.get_unchecked_mut(1), x.as_mut_ptr().add(1));
}RunReturns None if the pointer is null, or else returns a shared slice to
the value wrapped in Some. In contrast to as_ref, this does not require
that the value has to be initialized.
For the mutable counterpart see as_uninit_slice_mut.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be valid for reads for
ptr.len() * mem::size_of::<T>()many bytes, and it must be properly aligned. This means in particular:-
The entire memory range of this slice must be contained within a single allocated object! Slices can never span across multiple allocated objects.
-
The pointer must be aligned even for zero-length slices. One reason for this is that enum layout optimizations may rely on references (including slices of any length) being aligned and non-null to distinguish them from other data. You can obtain a pointer that is usable as
datafor zero-length slices usingNonNull::dangling().
-
-
The total size
ptr.len() * mem::size_of::<T>()of the slice must be no larger thanisize::MAX. See the safety documentation ofpointer::offset. -
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get mutated (except insideUnsafeCell).
This applies even if the result of this method is unused!
See also slice::from_raw_parts.
Returns None if the pointer is null, or else returns a unique slice to
the value wrapped in Some. In contrast to as_mut, this does not require
that the value has to be initialized.
For the shared counterpart see as_uninit_slice.
Safety
When calling this method, you have to ensure that either the pointer is null or all of the following is true:
-
The pointer must be valid for reads and writes for
ptr.len() * mem::size_of::<T>()many bytes, and it must be properly aligned. This means in particular:-
The entire memory range of this slice must be contained within a single allocated object! Slices can never span across multiple allocated objects.
-
The pointer must be aligned even for zero-length slices. One reason for this is that enum layout optimizations may rely on references (including slices of any length) being aligned and non-null to distinguish them from other data. You can obtain a pointer that is usable as
datafor zero-length slices usingNonNull::dangling().
-
-
The total size
ptr.len() * mem::size_of::<T>()of the slice must be no larger thanisize::MAX. See the safety documentation ofpointer::offset. -
You must enforce Rust’s aliasing rules, since the returned lifetime
'ais arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, for the duration of this lifetime, the memory the pointer points to must not get accessed (read or written) through any other pointer.
This applies even if the result of this method is unused!
See also slice::from_raw_parts_mut.
Trait Implementations
This method returns an ordering between self and other values if one exists. Read more
This method tests less than (for self and other) and is used by the < operator. Read more
This method tests less than or equal to (for self and other) and is used by the <=
operator. Read more
This method tests greater than (for self and other) and is used by the > operator. Read more
This method returns an ordering between self and other values if one exists. Read more
This method tests less than (for self and other) and is used by the < operator. Read more
This method tests less than or equal to (for self and other) and is used by the <=
operator. Read more
This method tests greater than (for self and other) and is used by the > operator. Read more
Auto Trait Implementations
impl<T: ?Sized> RefUnwindSafe for *const T where
T: RefUnwindSafe,
impl<T: ?Sized> RefUnwindSafe for *mut T where
T: RefUnwindSafe,
impl<T> RefUnwindSafe for *const [T] where
T: RefUnwindSafe,
impl<T> RefUnwindSafe for *mut [T] where
T: RefUnwindSafe,
Blanket Implementations
Mutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more