pointer - Rust
source link: https://doc.rust-lang.org/stable/std/primitive.pointer.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
pointer - Rust
slice_ptr_len
Ā #71146)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: *const [i8] = ptr::slice_from_raw_parts(ptr::null(), 3);
assert_eq!(slice.len(), 3);
Runslice_ptr_get
Ā #74265)Returns a raw pointer to the sliceās buffer.
This is equivalent to casting self
to *const T
, but more type-safe.
Examples
#![feature(slice_ptr_get)]
use std::ptr;
let slice: *const [i8] = ptr::slice_from_raw_parts(ptr::null(), 3);
assert_eq!(slice.as_ptr(), ptr::null());
Runpub unsafe fn get_unchecked<I>(Ā Ā Ā Ā self,Ā Ā Ā Ā index: I) -> *const <I as SliceIndex<[T]>>::OutputwhereĀ Ā Ā Ā I: SliceIndex<[T]>,
slice_ptr_get
Ā #74265)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 dereferenceable
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));
}
Runptr_as_uninit
Ā #75402)Returns 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:
This applies even if the result of this method is unused!
See also slice::from_raw_parts
.
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());
Run1.38.0 (const: 1.38.0) Ā· source
pub const fn cast<U>(self) -> *const U
Casts to a pointer of another type.
set_ptr_value
Ā #75091)Use the pointer value in a new pointer of another type.
In case val
is a (fat) pointer to an unsized type, this operation
will ignore the pointer part, whereas for (thin) pointers to sized
types, this has the same effect as a simple cast.
The resulting pointer will have provenance of self
, i.e., for a fat
pointer, this operation is semantically the same as creating a new
fat pointer with the data pointer value of self
but the metadata of
val
.
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 = thin.add(8).with_metadata_of(ptr);
println!("{:?}", &*ptr); // will print "3"
}
Run1.65.0 (const: 1.65.0) Ā· source
pub const fn cast_mut(self) -> *mut T
Changes constness without changing the type.
This is a bit safer than as
because it wouldnāt silently change the type if the code is
refactored.
ptr_to_from_bits
Ā #91126)Casts a pointer to its raw bits.
This is equivalent to as usize
, but is more specific to enhance readability.
The inverse method is from_bits
.
In particular, *p as usize
and p as usize
will both compile for
pointers to numeric types but do very different things, so using this
helps emphasize that reading the bits was intentional.
Examples
#![feature(ptr_to_from_bits)]
let array = [13, 42];
let p0: *const i32 = &array[0];
assert_eq!(<*const _>::from_bits(p0.to_bits()), p0);
let p1: *const i32 = &array[1];
assert_eq!(p1.to_bits() - p0.to_bits(), 4);
Runptr_to_from_bits
Ā #91126)Creates a pointer from its raw bits.
This is equivalent to as *const T
, but is more specific to enhance readability.
The inverse method is to_bits
.
Examples
#![feature(ptr_to_from_bits)]
use std::ptr::NonNull;
let dangling: *const u8 = NonNull::dangling().as_ptr();
assert_eq!(<*const u8>::from_bits(1), dangling);
Runstrict_provenance
Ā #95228)Gets the āaddressā portion of the pointer.
This is similar to self as usize
, which semantically discards provenance and
address-space information. However, unlike self as usize
, casting the returned address
back to a pointer yields invalid
, which is undefined behavior to dereference. To
properly restore the lost information and obtain a dereferenceable pointer, use
with_addr
or map_addr
.
If using those APIs is not possible because there is no way to preserve a pointer with the
required provenance, use expose_addr
and
from_exposed_addr
instead. However, note that this makes
your code less portable and less amenable to tools that check for compliance with the Rust
memory model.
On most platforms this will produce a value with the same bytes as the original pointer, because all the bytes are dedicated to describing the address. Platforms which need to store additional information in the pointer may perform a change of representation to produce a value containing only the address portion of the pointer. What that means is up to the platform to define.
This API and its claimed semantics are part of the Strict Provenance experiment, and as such
might change in the future (including possibly weakening this so it becomes wholly
equivalent to self as usize
). See the module documentation for details.
strict_provenance
Ā #95228)Gets the āaddressā portion of the pointer, and āexposesā the āprovenanceā part for future
use in from_exposed_addr
.
This is equivalent to self as usize
, which semantically discards provenance and
address-space information. Furthermore, this (like the as
cast) has the implicit
side-effect of marking the provenance as āexposedā, so on platforms that support it you can
later call from_exposed_addr
to reconstitute the original pointer including its
provenance. (Reconstructing address space information, if required, is your responsibility.)
Using this method means that code is not following Strict Provenance rules. Supporting
from_exposed_addr
complicates specification and reasoning and may not be supported by
tools that help you to stay conformant with the Rust memory model, so it is recommended to
use addr
wherever possible.
On most platforms this will produce a value with the same bytes as the original pointer,
because all the bytes are dedicated to describing the address. Platforms which need to store
additional information in the pointer may not support this operation, since the āexposeā
side-effect which is required for from_exposed_addr
to work is typically not
available.
This API and its claimed semantics are part of the Strict Provenance experiment, see the module documentation for details.
strict_provenance
Ā #95228)Creates a new pointer with the given address.
This performs the same operation as an addr as ptr
cast, but copies
the address-space and provenance of self
to the new pointer.
This allows us to dynamically preserve and propagate this important
information in a way that is otherwise impossible with a unary cast.
This is equivalent to using wrapping_offset
to offset
self
to the given address, and therefore has all the same capabilities and restrictions.
This API and its claimed semantics are part of the Strict Provenance experiment, see the module documentation for details.
strict_provenance
Ā #95228)Creates a new pointer by mapping self
ās address to a new one.
This is a convenience for with_addr
, see that method for details.
This API and its claimed semantics are part of the Strict Provenance experiment, see the module documentation for details.
ptr_metadata
Ā #81513)Decompose a (possibly wide) pointer into its address and metadata components.
The pointer can be later reconstructed with from_raw_parts
.
1.9.0 (const: unstable) Ā· source
pub unsafe fn as_ref<'a>(self) -> Option<&'a T>
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 ādereferenceableā 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
'a
is arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, while this reference exists, 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}!");
}
Runptr_as_uninit
Ā #75402)Returns 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 ādereferenceableā in the sense defined in the module documentation.
-
You must enforce Rustās aliasing rules, since the returned lifetime
'a
is arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. In particular, while this reference exists, 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());
}
}
Runconst: 1.61.0 Ā· source
pub const unsafe fn offset(self, count: isize) -> *const T
Calculates 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);
}
Runpointer_byte_offsets
Ā #96283)Calculates the offset from a pointer in bytes.
count
is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using offset on it. See that method for documentation
and safety requirements.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
1.16.0 (const: 1.61.0) Ā· source
pub const fn wrapping_offset(self, count: isize) -> *const T
Calculates 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);
}
Runpointer_byte_offsets
Ā #96283)Calculates the offset from a pointer in bytes using wrapping arithmetic.
count
is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using wrapping_offset on it. See that method
for documentation.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
ptr_mask
Ā #98290)Masks out bits of the pointer according to a mask.
This is convenience for ptr.map_addr(|a| a & mask)
.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
1.47.0 (const: 1.65.0) Ā· source
pub const unsafe fn offset_from(self, origin: *const T) -> isize
Calculates the distance between two pointers. The returned value is in
units of T: the distance in bytes 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
}
Runpointer_byte_offsets
Ā #96283)Calculates the distance between two pointers. The returned value is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using offset_from on it. See that method for
documentation and safety requirements.
For non-Sized
pointees this operation considers only the data pointers,
ignoring the metadata.
pub unsafe fn sub_ptr(self, origin: *const T) -> usize
ptr_sub_ptr
Ā #95892)Calculates the distance between two pointers, where itās known that
self
is equal to or greater than origin
. The returned value is in
units of T: the distance in bytes is divided by mem::size_of::<T>()
.
This computes the same value that offset_from
would compute, but with the added precondition that that the offset is
guaranteed to be non-negative. This method is equivalent to
usize::from(self.offset_from(origin)).unwrap_unchecked()
,
but it provides slightly more information to the optimizer, which can
sometimes allow it to optimize slightly better with some backends.
This method can be though of as recovering the count
that was passed
to add
(or, with the parameters in the other order,
to sub
). The following are all equivalent, assuming
that their safety preconditions are met:
ptr.sub_ptr(origin) == count
origin.add(count) == ptr
ptr.sub(count) == origin
RunSafety
-
The distance between the pointers must be non-negative (
self >= origin
) -
All the safety conditions of
offset_from
apply to this method as well; see it for the full details.
Importantly, despite the return type of this method being able to represent
a larger offset, itās still not permitted to pass pointers which differ
by more than isize::MAX
bytes. As such, the result of this method will
always be less than or equal to isize::MAX as usize
.
Panics
This function panics if T
is a Zero-Sized Type (āZSTā).
Examples
#![feature(ptr_sub_ptr)]
let a = [0; 5];
let ptr1: *const i32 = &a[1];
let ptr2: *const i32 = &a[3];
unsafe {
assert_eq!(ptr2.sub_ptr(ptr1), 2);
assert_eq!(ptr1.add(2), ptr2);
assert_eq!(ptr2.sub(2), ptr1);
assert_eq!(ptr2.sub_ptr(ptr2), 0);
}
// This would be incorrect, as the pointers are not correctly ordered:
// ptr1.sub_ptr(ptr2)
Runconst_raw_ptr_comparison
Ā #53020)Returns whether two pointers are guaranteed to be equal.
At runtime this function behaves like Some(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 None
for pointers that later actually turn out to have its equality known.
But when it returns Some
, the pointersā equality is guaranteed to be known.
The return value may change from Some
to None
and vice versa depending on the compiler
version and unsafe code must not
rely on the result of this function for soundness. It is suggested to only use this function
for performance optimizations where spurious None
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.
const_raw_ptr_comparison
Ā #53020)Returns whether two pointers are guaranteed to be inequal.
At runtime this function behaves like Some(self == other)
.
However, in some contexts (e.g., compile-time evaluation),
it is not always possible to determine inequality of two pointers, so this function may
spuriously return None
for pointers that later actually turn out to have its inequality known.
But when it returns Some
, the pointersā inequality is guaranteed to be known.
The return value may change from Some
to None
and vice versa depending on the compiler
version and unsafe code must not
rely on the result of this function for soundness. It is suggested to only use this function
for performance optimizations where spurious None
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.
1.26.0 (const: 1.61.0) Ā· source
pub const unsafe fn add(self, count: usize) -> *const T
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);
}
Runpointer_byte_offsets
Ā #96283)Calculates the offset from a pointer in bytes (convenience for .byte_offset(count as isize)
).
count
is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using add on it. See that method for documentation
and safety requirements.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
1.26.0 (const: 1.61.0) Ā· source
pub const unsafe fn sub(self, count: usize) -> *const T
Calculates 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::MAX
bytes. -
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);
}
Runpointer_byte_offsets
Ā #96283)Calculates the offset from a pointer in bytes (convenience for
.byte_offset((count as isize).wrapping_neg())
).
count
is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using sub on it. See that method for documentation
and safety requirements.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
1.26.0 (const: 1.61.0) Ā· source
pub const fn wrapping_add(self, count: usize) -> *const T
Calculates 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);
}
Runpointer_byte_offsets
Ā #96283)Calculates the offset from a pointer in bytes using wrapping arithmetic.
(convenience for .wrapping_byte_offset(count as isize)
)
count
is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using wrapping_add on it. See that method for documentation.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
1.26.0 (const: 1.61.0) Ā· source
pub const fn wrapping_sub(self, count: usize) -> *const T
Calculates 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);
}
Runpointer_byte_offsets
Ā #96283)Calculates the offset from a pointer in bytes using wrapping arithmetic.
(convenience for .wrapping_offset((count as isize).wrapping_neg())
)
count
is in units of bytes.
This is purely a convenience for casting to a u8
pointer and
using wrapping_sub on it. See that method for documentation.
For non-Sized
pointees this operation changes only the data pointer,
leaving the metadata untouched.
1.26.0 (const: unstable) Ā· source
pub unsafe fn read(self) -> T
Reads the value from self
without moving it. This leaves the
memory in self
unchanged.
See ptr::read
for safety concerns and examples.
1.26.0 Ā· source
pub unsafe fn read_volatile(self) -> T
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.
1.26.0 (const: unstable) Ā· source
pub unsafe fn read_unaligned(self) -> T
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.
1.26.0 (const: 1.63.0) Ā· source
pub const unsafe fn copy_to(self, dest: *mut T, count: usize)
Copies count * size_of<T>
bytes from self
to dest
. The source
and destination may overlap.
NOTE: this has the same argument order as ptr::copy
.
See ptr::copy
for safety concerns and examples.
1.26.0 (const: 1.63.0) Ā· source
pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize)
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
use std::mem::align_of;
let x = [5_u8, 6, 7, 8, 9];
let ptr = x.as_ptr();
let offset = ptr.align_offset(align_of::<u16>());
if offset < x.len() - 1 {
let u16_ptr = ptr.add(offset).cast::<u16>();
assert!(*u16_ptr == u16::from_ne_bytes([5, 6]) || *u16_ptr == u16::from_ne_bytes([6, 7]));
} else {
// while the pointer can be aligned via `offset`, it would point
// outside the allocation
}
Runpointer_is_aligned
Ā #96284)Returns whether the pointer is properly aligned for T
.
pointer_is_aligned
Ā #96284)Returns whether the pointer is aligned to align
.
For non-Sized
pointees this operation considers only the data pointer,
ignoring the metadata.
Panics
The function panics if align
is not a power-of-two (this includes 0).
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK