Struct dlopen::symbor::PtrOrNull
[−]
[src]
pub struct PtrOrNull<'lib, T: 'lib> { /* fields omitted */ }
Safe wrapper around const pointer.
It is recommended only for obtaining pointers that can have null value.
Methods
impl<'lib, T> PtrOrNull<'lib, T>
[src]
Methods from Deref<Target = *const T>
fn is_null(self) -> bool
1.0.0[src]
Returns true
if the pointer is null.
Examples
Basic usage:
let s: &str = "Follow the rabbit"; let ptr: *const u8 = s.as_ptr(); assert!(!ptr.is_null());
unsafe fn as_ref<'a>(self) -> Option<&'a T>
1.9.0[src]
Returns None
if the pointer is null, or else returns a reference to
the value wrapped in Some
.
Safety
While this method and its mutable counterpart are useful for null-safety, it is important to note that this is still an unsafe operation because the returned value could be pointing to invalid memory.
Additionally, the lifetime 'a
returned is arbitrarily chosen and does
not necessarily reflect the actual lifetime of the data.
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); } }
unsafe fn offset(self, count: isize) -> *const T
1.0.0[src]
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 an allocated object.
The computed offset, in bytes, cannot overflow or underflow 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().offset(vec.len() as isize)
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); }
fn wrapping_offset(self, count: isize) -> *const T
1.16.0[src]
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
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .offset(count)
instead when possible, because offset
allows the compiler to optimize better.
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); }
fn offset_to(self, other: *const T) -> Option<isize>
[src]
offset_to
)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>()
.
If the address different between the two pointers ia not a multiple of
mem::size_of::<T>()
then the result of the division is rounded towards
zero.
This function returns None
if T
is a zero-sized typed.
Examples
Basic usage:
#![feature(offset_to)] fn main() { let a = [0; 5]; let ptr1: *const i32 = &a[1]; let ptr2: *const i32 = &a[3]; assert_eq!(ptr1.offset_to(ptr2), Some(2)); assert_eq!(ptr2.offset_to(ptr1), Some(-2)); assert_eq!(unsafe { ptr1.offset(2) }, ptr2); assert_eq!(unsafe { ptr2.offset(-2) }, ptr1); }
unsafe fn add(self, count: usize) -> *const T
[src]
pointer_methods
)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 an allocated object.
The computed offset, in bytes, cannot overflow or underflow 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_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:
#![feature(pointer_methods)] let s: &str = "123"; let ptr: *const u8 = s.as_ptr(); unsafe { println!("{}", *ptr.add(1) as char); println!("{}", *ptr.add(2) as char); }
unsafe fn sub(self, count: usize) -> *const T
[src]
pointer_methods
)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 an 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_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:
#![feature(pointer_methods)] 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); }
fn wrapping_add(self, count: usize) -> *const T
[src]
pointer_methods
)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
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .add(count)
instead when possible, because add
allows the compiler to optimize better.
Examples
Basic usage:
#![feature(pointer_methods)] // 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); }
fn wrapping_sub(self, count: usize) -> *const T
[src]
pointer_methods
)Calculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset((count as isize).wrapping_sub())
)
count
is in units of T; e.g. a count
of 3 represents a pointer
offset of 3 * size_of::<T>()
bytes.
Safety
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .sub(count)
instead when possible, because sub
allows the compiler to optimize better.
Examples
Basic usage:
#![feature(pointer_methods)] // 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); }
unsafe fn read(self) -> T
[src]
pointer_methods
)Reads the value from self
without moving it. This leaves the
memory in self
unchanged.
Safety
Beyond accepting a raw pointer, this is unsafe because it semantically
moves the value out of self
without preventing further usage of self
.
If T
is not Copy
, then care must be taken to ensure that the value at
self
is not used before the data is overwritten again (e.g. with write
,
zero_memory
, or copy_memory
). Note that *self = foo
counts as a use
because it will attempt to drop the value previously at *self
.
The pointer must be aligned; use read_unaligned
if that is not the case.
Examples
Basic usage:
#![feature(pointer_methods)] let x = 12; let y = &x as *const i32; unsafe { assert_eq!(y.read(), 12); }
unsafe fn read_volatile(self) -> T
[src]
pointer_methods
)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.
Notes
Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time. That being said, the semantics will almost always end up pretty similar to C11's definition of volatile.
The compiler shouldn't change the relative order or number of volatile
memory operations. However, volatile memory operations on zero-sized types
(e.g. if a zero-sized type is passed to read_volatile
) are no-ops
and may be ignored.
Safety
Beyond accepting a raw pointer, this is unsafe because it semantically
moves the value out of self
without preventing further usage of self
.
If T
is not Copy
, then care must be taken to ensure that the value at
self
is not used before the data is overwritten again (e.g. with write
,
zero_memory
, or copy_memory
). Note that *self = foo
counts as a use
because it will attempt to drop the value previously at *self
.
Examples
Basic usage:
#![feature(pointer_methods)] let x = 12; let y = &x as *const i32; unsafe { assert_eq!(y.read_volatile(), 12); }
unsafe fn read_unaligned(self) -> T
[src]
pointer_methods
)Reads the value from self
without moving it. This leaves the
memory in self
unchanged.
Unlike read
, the pointer may be unaligned.
Safety
Beyond accepting a raw pointer, this is unsafe because it semantically
moves the value out of self
without preventing further usage of self
.
If T
is not Copy
, then care must be taken to ensure that the value at
self
is not used before the data is overwritten again (e.g. with write
,
zero_memory
, or copy_memory
). Note that *self = foo
counts as a use
because it will attempt to drop the value previously at *self
.
Examples
Basic usage:
#![feature(pointer_methods)] let x = 12; let y = &x as *const i32; unsafe { assert_eq!(y.read_unaligned(), 12); }
unsafe fn copy_to(self, dest: *mut T, count: usize)
[src]
pointer_methods
)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
.
This is semantically equivalent to C's memmove
.
Safety
Care must be taken with the ownership of self
and dest
.
This method semantically moves the values of self
into dest
.
However it does not drop the contents of self
, or prevent the contents
of dest
from being dropped or used.
Examples
Efficiently create a Rust vector from an unsafe buffer:
#![feature(pointer_methods)] unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> { let mut dst = Vec::with_capacity(elts); dst.set_len(elts); ptr.copy_to(dst.as_mut_ptr(), elts); dst }
unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize)
[src]
pointer_methods
)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
.
copy_nonoverlapping
is semantically equivalent to C's memcpy
.
Safety
Beyond requiring that the program must be allowed to access both regions
of memory, it is Undefined Behavior for source and destination to
overlap. Care must also be taken with the ownership of self
and
self
. This method semantically moves the values of self
into dest
.
However it does not drop the contents of dest
, or prevent the contents
of self
from being dropped or used.
Examples
Efficiently create a Rust vector from an unsafe buffer:
#![feature(pointer_methods)] unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> { let mut dst = Vec::with_capacity(elts); dst.set_len(elts); ptr.copy_to_nonoverlapping(dst.as_mut_ptr(), elts); dst }
fn align_offset(self, align: usize) -> usize
[src]
align_offset
)Computes the byte offset that needs to be applied in order to
make the pointer aligned to align
.
If it is not possible to align the pointer, the implementation returns
usize::max_value()
.
There are no guarantees whatsover 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.
Examples
Accessing adjacent u8
as u16
let x = [5u8, 6u8, 7u8, 8u8, 9u8]; let ptr = &x[n] as *const u8; let offset = ptr.align_offset(align_of::<u16>()); if offset < x.len() - n - 1 { let u16_ptr = ptr.offset(offset as isize) as *const u16; assert_ne!(*u16_ptr, 500); } else { // while the pointer can be aligned via `offset`, it would point // outside the allocation }
fn is_null(self) -> bool
1.0.0[src]
Returns true
if the pointer is null.
Examples
Basic usage:
let mut s = [1, 2, 3]; let ptr: *mut u32 = s.as_mut_ptr(); assert!(!ptr.is_null());
unsafe fn as_ref<'a>(self) -> Option<&'a T>
1.9.0[src]
Returns None
if the pointer is null, or else returns a reference to
the value wrapped in Some
.
Safety
While this method and its mutable counterpart are useful for null-safety, it is important to note that this is still an unsafe operation because the returned value could be pointing to invalid memory.
Additionally, the lifetime 'a
returned is arbitrarily chosen and does
not necessarily reflect the actual lifetime of the data.
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); } }
unsafe fn offset(self, count: isize) -> *mut T
1.0.0[src]
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 an allocated object.
The computed offset, in bytes, cannot overflow or underflow 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().offset(vec.len() as isize)
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)); }
fn wrapping_offset(self, count: isize) -> *mut T
1.16.0[src]
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
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .offset(count)
instead when possible, because offset
allows the compiler to optimize better.
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]);
unsafe fn as_mut<'a>(self) -> Option<&'a mut T>
1.9.0[src]
Returns None
if the pointer is null, or else returns a mutable
reference to the value wrapped in Some
.
Safety
As with as_ref
, this is unsafe because it cannot verify the validity
of the returned pointer, nor can it ensure that the lifetime 'a
returned is indeed a valid lifetime for the contained data.
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]".
fn offset_to(self, other: *const T) -> Option<isize>
[src]
offset_to
)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>()
.
If the address different between the two pointers ia not a multiple of
mem::size_of::<T>()
then the result of the division is rounded towards
zero.
This function returns None
if T
is a zero-sized typed.
Examples
Basic usage:
#![feature(offset_to)] fn main() { let mut a = [0; 5]; let ptr1: *mut i32 = &mut a[1]; let ptr2: *mut i32 = &mut a[3]; assert_eq!(ptr1.offset_to(ptr2), Some(2)); assert_eq!(ptr2.offset_to(ptr1), Some(-2)); assert_eq!(unsafe { ptr1.offset(2) }, ptr2); assert_eq!(unsafe { ptr2.offset(-2) }, ptr1); }
fn align_offset(self, align: usize) -> usize
[src]
align_offset
)Computes the byte offset that needs to be applied in order to
make the pointer aligned to align
.
If it is not possible to align the pointer, the implementation returns
usize::max_value()
.
There are no guarantees whatsover 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.
Examples
Accessing adjacent u8
as u16
let x = [5u8, 6u8, 7u8, 8u8, 9u8]; let ptr = &x[n] as *const u8; let offset = ptr.align_offset(align_of::<u16>()); if offset < x.len() - n - 1 { let u16_ptr = ptr.offset(offset as isize) as *const u16; assert_ne!(*u16_ptr, 500); } else { // while the pointer can be aligned via `offset`, it would point // outside the allocation }
unsafe fn add(self, count: usize) -> *mut T
[src]
pointer_methods
)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 an allocated object.
The computed offset, in bytes, cannot overflow or underflow 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_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:
#![feature(pointer_methods)] let s: &str = "123"; let ptr: *const u8 = s.as_ptr(); unsafe { println!("{}", *ptr.add(1) as char); println!("{}", *ptr.add(2) as char); }
unsafe fn sub(self, count: usize) -> *mut T
[src]
pointer_methods
)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 an 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_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:
#![feature(pointer_methods)] 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); }
fn wrapping_add(self, count: usize) -> *mut T
[src]
pointer_methods
)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
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .add(count)
instead when possible, because add
allows the compiler to optimize better.
Examples
Basic usage:
#![feature(pointer_methods)] // 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); }
fn wrapping_sub(self, count: usize) -> *mut T
[src]
pointer_methods
)Calculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset((count as isize).wrapping_sub())
)
count
is in units of T; e.g. a count
of 3 represents a pointer
offset of 3 * size_of::<T>()
bytes.
Safety
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .sub(count)
instead when possible, because sub
allows the compiler to optimize better.
Examples
Basic usage:
#![feature(pointer_methods)] // 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); }
unsafe fn read(self) -> T
[src]
pointer_methods
)Reads the value from self
without moving it. This leaves the
memory in self
unchanged.
Safety
Beyond accepting a raw pointer, this is unsafe because it semantically
moves the value out of self
without preventing further usage of self
.
If T
is not Copy
, then care must be taken to ensure that the value at
self
is not used before the data is overwritten again (e.g. with write
,
zero_memory
, or copy_memory
). Note that *self = foo
counts as a use
because it will attempt to drop the value previously at *self
.
The pointer must be aligned; use read_unaligned
if that is not the case.
Examples
Basic usage:
#![feature(pointer_methods)] let x = 12; let y = &x as *const i32; unsafe { assert_eq!(y.read(), 12); }
unsafe fn read_volatile(self) -> T
[src]
pointer_methods
)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.
Notes
Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time. That being said, the semantics will almost always end up pretty similar to C11's definition of volatile.
The compiler shouldn't change the relative order or number of volatile
memory operations. However, volatile memory operations on zero-sized types
(e.g. if a zero-sized type is passed to read_volatile
) are no-ops
and may be ignored.
Safety
Beyond accepting a raw pointer, this is unsafe because it semantically
moves the value out of self
without preventing further usage of self
.
If T
is not Copy
, then care must be taken to ensure that the value at
src
is not used before the data is overwritten again (e.g. with write
,
zero_memory
, or copy_memory
). Note that *self = foo
counts as a use
because it will attempt to drop the value previously at *self
.
Examples
Basic usage:
#![feature(pointer_methods)] let x = 12; let y = &x as *const i32; unsafe { assert_eq!(y.read_volatile(), 12); }
unsafe fn read_unaligned(self) -> T
[src]
pointer_methods
)Reads the value from self
without moving it. This leaves the
memory in self
unchanged.
Unlike read
, the pointer may be unaligned.
Safety
Beyond accepting a raw pointer, this is unsafe because it semantically
moves the value out of self
without preventing further usage of self
.
If T
is not Copy
, then care must be taken to ensure that the value at
self
is not used before the data is overwritten again (e.g. with write
,
zero_memory
, or copy_memory
). Note that *self = foo
counts as a use
because it will attempt to drop the value previously at *self
.
Examples
Basic usage:
#![feature(pointer_methods)] let x = 12; let y = &x as *const i32; unsafe { assert_eq!(y.read_unaligned(), 12); }
unsafe fn copy_to(self, dest: *mut T, count: usize)
[src]
pointer_methods
)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
.
This is semantically equivalent to C's memmove
.
Safety
Care must be taken with the ownership of self
and dest
.
This method semantically moves the values of self
into dest
.
However it does not drop the contents of self
, or prevent the contents
of dest
from being dropped or used.
Examples
Efficiently create a Rust vector from an unsafe buffer:
#![feature(pointer_methods)] unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> { let mut dst = Vec::with_capacity(elts); dst.set_len(elts); ptr.copy_to(dst.as_mut_ptr(), elts); dst }
unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize)
[src]
pointer_methods
)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
.
copy_nonoverlapping
is semantically equivalent to C's memcpy
.
Safety
Beyond requiring that the program must be allowed to access both regions
of memory, it is Undefined Behavior for source and destination to
overlap. Care must also be taken with the ownership of self
and
self
. This method semantically moves the values of self
into dest
.
However it does not drop the contents of dest
, or prevent the contents
of self
from being dropped or used.
Examples
Efficiently create a Rust vector from an unsafe buffer:
#![feature(pointer_methods)] unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> { let mut dst = Vec::with_capacity(elts); dst.set_len(elts); ptr.copy_to_nonoverlapping(dst.as_mut_ptr(), elts); dst }
unsafe fn copy_from(self, src: *const T, count: usize)
[src]
pointer_methods
)Copies count * size_of<T>
bytes from src
to self
. The source
and destination may overlap.
NOTE: this has the opposite argument order of ptr::copy
.
This is semantically equivalent to C's memmove
.
Safety
Care must be taken with the ownership of src
and self
.
This method semantically moves the values of src
into self
.
However it does not drop the contents of self
, or prevent the contents
of src
from being dropped or used.
Examples
Efficiently create a Rust vector from an unsafe buffer:
#![feature(pointer_methods)] unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> { let mut dst = Vec::with_capacity(elts); dst.set_len(elts); dst.as_mut_ptr().copy_from(ptr, elts); dst }
unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize)
[src]
pointer_methods
)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
.
copy_nonoverlapping
is semantically equivalent to C's memcpy
.
Safety
Beyond requiring that the program must be allowed to access both regions
of memory, it is Undefined Behavior for source and destination to
overlap. Care must also be taken with the ownership of src
and
self
. This method semantically moves the values of src
into self
.
However it does not drop the contents of self
, or prevent the contents
of src
from being dropped or used.
Examples
Efficiently create a Rust vector from an unsafe buffer:
#![feature(pointer_methods)] unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> { let mut dst = Vec::with_capacity(elts); dst.set_len(elts); dst.as_mut_ptr().copy_from_nonoverlapping(ptr, elts); dst }
unsafe fn drop_in_place(self)
[src]
pointer_methods
)Executes the destructor (if any) of the pointed-to value.
This has two use cases:
It is required to use
drop_in_place
to drop unsized types like trait objects, because they can't be read out onto the stack and dropped normally.It is friendlier to the optimizer to do this over
ptr::read
when dropping manually allocated memory (e.g. when writing Box/Rc/Vec), as the compiler doesn't need to prove that it's sound to elide the copy.
Safety
This has all the same safety problems as ptr::read
with respect to
invalid pointers, types, and double drops.
unsafe fn write(self, val: T)
[src]
pointer_methods
)Overwrites a memory location with the given value without reading or dropping the old value.
Safety
This operation is marked unsafe because it writes through a raw pointer.
It does not drop the contents of self
. This is safe, but it could leak
allocations or resources, so care must be taken not to overwrite an object
that should be dropped.
Additionally, it does not drop val
. Semantically, val
is moved into the
location pointed to by self
.
This is appropriate for initializing uninitialized memory, or overwriting
memory that has previously been read
from.
The pointer must be aligned; use write_unaligned
if that is not the case.
Examples
Basic usage:
#![feature(pointer_methods)] let mut x = 0; let y = &mut x as *mut i32; let z = 12; unsafe { y.write(z); assert_eq!(y.read(), 12); }
unsafe fn write_bytes(self, val: u8, count: usize)
[src]
pointer_methods
)Invokes memset on the specified pointer, setting count * size_of::<T>()
bytes of memory starting at self
to val
.
Examples
#![feature(pointer_methods)] let mut vec = vec![0; 4]; unsafe { let vec_ptr = vec.as_mut_ptr(); vec_ptr.write_bytes(b'a', 2); } assert_eq!(vec, [b'a', b'a', 0, 0]);
unsafe fn write_volatile(self, val: T)
[src]
pointer_methods
)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.
Notes
Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time. That being said, the semantics will almost always end up pretty similar to C11's definition of volatile.
The compiler shouldn't change the relative order or number of volatile
memory operations. However, volatile memory operations on zero-sized types
(e.g. if a zero-sized type is passed to write_volatile
) are no-ops
and may be ignored.
Safety
This operation is marked unsafe because it accepts a raw pointer.
It does not drop the contents of self
. This is safe, but it could leak
allocations or resources, so care must be taken not to overwrite an object
that should be dropped.
This is appropriate for initializing uninitialized memory, or overwriting
memory that has previously been read
from.
Examples
Basic usage:
#![feature(pointer_methods)] let mut x = 0; let y = &mut x as *mut i32; let z = 12; unsafe { y.write_volatile(z); assert_eq!(y.read_volatile(), 12); }
unsafe fn write_unaligned(self, val: T)
[src]
pointer_methods
)Overwrites a memory location with the given value without reading or dropping the old value.
Unlike write
, the pointer may be unaligned.
Safety
This operation is marked unsafe because it writes through a raw pointer.
It does not drop the contents of self
. This is safe, but it could leak
allocations or resources, so care must be taken not to overwrite an object
that should be dropped.
Additionally, it does not drop src
. Semantically, src
is moved into the
location pointed to by dst
.
This is appropriate for initializing uninitialized memory, or overwriting
memory that has previously been read
from.
Examples
Basic usage:
#![feature(pointer_methods)] let mut x = 0; let y = &mut x as *mut i32; let z = 12; unsafe { y.write_unaligned(z); assert_eq!(y.read_unaligned(), 12); }
unsafe fn replace(self, src: T) -> T
[src]
pointer_methods
)Replaces the value at self
with src
, returning the old
value, without dropping either.
Safety
This is only unsafe because it accepts a raw pointer.
Otherwise, this operation is identical to mem::replace
.
unsafe fn swap(self, with: *mut T)
[src]
pointer_methods
)Swaps the values at two mutable locations of the same type, without
deinitializing either. They may overlap, unlike mem::swap
which is
otherwise equivalent.
Safety
This function copies the memory through the raw pointers passed to it as arguments.
Ensure that these pointers are valid before calling swap
.
Trait Implementations
impl<'lib, T: Debug + 'lib> Debug for PtrOrNull<'lib, T>
[src]
impl<'lib, T: Clone + 'lib> Clone for PtrOrNull<'lib, T>
[src]
fn clone(&self) -> PtrOrNull<'lib, T>
[src]
Returns a copy of the value. Read more
fn clone_from(&mut self, source: &Self)
1.0.0[src]
Performs copy-assignment from source
. Read more
impl<'lib, T: Copy + 'lib> Copy for PtrOrNull<'lib, T>
[src]
impl<'lib, T> FromRawResult for PtrOrNull<'lib, T>
[src]
unsafe fn from_raw_result(
raw_result: Result<PtrOrNull<'a, ()>, Error>
) -> Result<Self, Error>
[src]
raw_result: Result<PtrOrNull<'a, ()>, Error>
) -> Result<Self, Error>
impl<'lib, T> Deref for PtrOrNull<'lib, T>
[src]
type Target = *const T
The resulting type after dereferencing.
fn deref(&self) -> &*const T
[src]
Dereferences the value.