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.

Examples

Basic usage:

let s: &str = "Follow the rabbit";
let ptr: *const u8 = s.as_ptr();
assert!(!ptr.is_null());

Cast to a pointer to a different type

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.

When calling this method, you have to ensure that if the pointer is non-NULL, then it is properly aligned, dereferencable (for the whole size of T) and points to an initialized instance of T. 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.)

Additionally, the lifetime 'a returned is arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. It is up to the caller to ensure that for the duration of this lifetime, the memory this pointer points to does not get written to outside of UnsafeCell<U>.

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);
    }
}

Null-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);
}

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 2⁶³ 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);
}

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). In particular, the resulting pointer may not be used to access a different allocated object than the one self points to. In other words, x.wrapping_offset(y.wrapping_offset_from(x)) is not the same as y, and dereferencing it is undefined behavior unless x and y point into the same allocated object.

Always use .offset(count) instead when possible, because offset allows the compiler to optimize better. If you need to cross object boundaries, cast the pointer to an integer and do the arithmetic there.

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);
}

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.

• The distance between the pointers, in bytes, cannot overflow an isize.

• The distance between the pointers, in bytes, must be an exact multiple of the size of T.

• The distance being in bounds cannot rely on "wrapping around" the address space.

The compiler and standard library generally try 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 ptr_into_vec.offset_from(vec.as_ptr()) 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 2⁶³ 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_from instead if these constraints are difficult to satisfy. The only advantage of this method is that it enables more aggressive compiler optimizations.

Panics

This function panics if T is a Zero-Sized Type ("ZST").

Examples

Basic usage:

#![feature(ptr_offset_from)]

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);
}

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 is not a multiple of mem::size_of::<T>() then the result of the division is rounded towards zero.

Though this method is safe for any two pointers, note that its result will be mostly useless if the two pointers aren't into the same allocated object, for example if they point to two different local variables.

Panics

This function panics if T is a zero-sized type.

Examples

Basic usage:

#![feature(ptr_wrapping_offset_from)]

let a = [0; 5];
let ptr1: *const i32 = &a[1];
let ptr2: *const i32 = &a[3];
assert_eq!(ptr2.wrapping_offset_from(ptr1), 2);
assert_eq!(ptr1.wrapping_offset_from(ptr2), -2);
assert_eq!(ptr1.wrapping_offset(2), ptr2);
assert_eq!(ptr2.wrapping_offset(-2), ptr1);

let ptr1: *const i32 = 3 as _;
let ptr2: *const i32 = 13 as _;
assert_eq!(ptr2.wrapping_offset_from(ptr1), 2);

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 2⁶³ 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.add(1) as char);
    println!("{}", *ptr.add(2) as char);
}

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 2⁶³ 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";

unsafe {
    let end: *const u8 = s.as_ptr().add(3);
    println!("{}", *end.sub(1) as char);
    println!("{}", *end.sub(2) as char);
}

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:

// 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);
}

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:

// 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);
}

Reads 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 overlap.

NOTE: this has the same argument order as ptr::copy.

See ptr::copy 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_value().

The offset is expressed in number of T elements, and not bytes. The value returned can be used with the offset or offset_to methods.

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.

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[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
}

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.

Examples

Basic usage:

let mut s = [1, 2, 3];
let ptr: *mut u32 = s.as_mut_ptr();
assert!(!ptr.is_null());

Cast to a pointer to a different type

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.

When calling this method, you have to ensure that if the pointer is non-NULL, then it is properly aligned, dereferencable (for the whole size of T) and points to an initialized instance of T. 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.)

Additionally, the lifetime 'a returned is arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. It is up to the caller to ensure that for the duration of this lifetime, the memory this pointer points to does not get written to outside of UnsafeCell<U>.

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);
    }
}

Null-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);
}

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 2⁶³ 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));
}

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). In particular, the resulting pointer may not be used to access a different allocated object than the one self points to. In other words, x.wrapping_offset(y.wrapping_offset_from(x)) is not the same as y, and dereferencing it is undefined behavior unless x and y point into the same allocated object.

Always use .offset(count) instead when possible, because offset allows the compiler to optimize better. If you need to cross object boundaries, cast the pointer to an integer and do the arithmetic there.

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]);

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.

When calling this method, you have to ensure that if the pointer is non-NULL, then it is properly aligned, dereferencable (for the whole size of T) and points to an initialized instance of T. 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.)

Additionally, the lifetime 'a returned is arbitrarily chosen and does not necessarily reflect the actual lifetime of the data. It is up to the caller to ensure that for the duration of this lifetime, the memory this pointer points to does not get accessed through any other pointer.

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]".

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.

• The distance between the pointers, in bytes, cannot overflow an isize.

• The distance between the pointers, in bytes, must be an exact multiple of the size of T.

• The distance being in bounds cannot rely on "wrapping around" the address space.

The compiler and standard library generally try 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 ptr_into_vec.offset_from(vec.as_ptr()) 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 2⁶³ 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_from instead if these constraints are difficult to satisfy. The only advantage of this method is that it enables more aggressive compiler optimizations.

Panics

This function panics if T is a Zero-Sized Type ("ZST").

Examples

Basic usage:

#![feature(ptr_offset_from)]

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);
}

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 is not a multiple of mem::size_of::<T>() then the result of the division is rounded towards zero.

Though this method is safe for any two pointers, note that its result will be mostly useless if the two pointers aren't into the same allocated object, for example if they point to two different local variables.

Panics

This function panics if T is a zero-sized type.

Examples

Basic usage:

#![feature(ptr_wrapping_offset_from)]

let mut a = [0; 5];
let ptr1: *mut i32 = &mut a[1];
let ptr2: *mut i32 = &mut a[3];
assert_eq!(ptr2.wrapping_offset_from(ptr1), 2);
assert_eq!(ptr1.wrapping_offset_from(ptr2), -2);
assert_eq!(ptr1.wrapping_offset(2), ptr2);
assert_eq!(ptr2.wrapping_offset(-2), ptr1);

let ptr1: *mut i32 = 3 as _;
let ptr2: *mut i32 = 13 as _;
assert_eq!(ptr2.wrapping_offset_from(ptr1), 2);

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 2⁶³ 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.add(1) as char);
    println!("{}", *ptr.add(2) as char);
}

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 2⁶³ 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";

unsafe {
    let end: *const u8 = s.as_ptr().add(3);
    println!("{}", *end.sub(1) as char);
    println!("{}", *end.sub(2) as char);
}

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:

// 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);
}

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:

// 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);
}

Reads 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 overlap.

NOTE: this has the same argument order as ptr::copy.

See ptr::copy 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.

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.

See ptr::copy for safety concerns and examples.

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_value().

The offset is expressed in number of T elements, and not bytes. The value returned can be used with the offset or offset_to methods.

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.

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[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
}