# Primitive Type pointer 1.0.0[−]

Raw, unsafe pointers, `*const T`, and `*mut T`.

See also the `std::ptr` module.

Working with raw pointers in Rust is uncommon, typically limited to a few patterns.

Use the `null` and `null_mut` functions to create null pointers, and the `is_null` method of the `*const T` and `*mut T` types to check for null. The `*const T` and `*mut T` types also define the `offset` method, for pointer math.

# Common ways to create raw pointers

## 1. Coerce a reference (`&T`) or mutable reference (`&mut T`).

    let my_num: i32 = 10;
    let my_num_ptr: *const i32 = &my_num;
    let mut my_speed: i32 = 88;
    let my_speed_ptr: *mut i32 = &mut my_speed;Run

To get a pointer to a boxed value, dereference the box:

    let my_num: Box<i32> = Box::new(10);
    let my_num_ptr: *const i32 = &*my_num;
    let mut my_speed: Box<i32> = Box::new(88);
    let my_speed_ptr: *mut i32 = &mut *my_speed;Run

This does not take ownership of the original allocation and requires no resource management later, but you must not use the pointer after its lifetime.

## 2. Consume a box (`Box<T>`).

The `into_raw` function consumes a box and returns the raw pointer. It doesn't destroy `T` or deallocate any memory.

    let my_speed: Box<i32> = Box::new(88);
    let my_speed: *mut i32 = Box::into_raw(my_speed);

    // By taking ownership of the original `Box<T>` though
    // we are obligated to put it together later to be destroyed.
    unsafe {
        drop(Box::from_raw(my_speed));
    }Run

Note that here the call to `drop` is for clarity - it indicates that we are done with the given value and it should be destroyed.

## 3. Get it from C.

    extern crate libc;

    use std::mem;

    fn main() {
        unsafe {
            let my_num: *mut i32 = libc::malloc(mem::size_of::<i32>()) as *mut i32;
            if my_num.is_null() {
                panic!("failed to allocate memory");
            }
            libc::free(my_num as *mut libc::c_void);
        }
    }Run

Usually you wouldn't literally use `malloc` and `free` from Rust, but C APIs hand out a lot of pointers generally, so are a common source of raw pointers in Rust.

## Methods

###

`impl<T> *const T where T: ?Sized,`

[src]

####

`pub fn is_null(self) -> bool`

[src]

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());Run

####

`pub 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);
        }
    }Run

####

`pub unsafe fn offset(self, count: isize) -> *const T`

[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 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().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);
    }Run

####

`pub 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`). 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);
    }Run

####

`pub fn offset_to(self, other: *const T) -> Option<isize>`

[src]

Deprecated since 1.27.0

: Replaced by `wrapping_offset_from`, with the opposite argument order. If you're writing unsafe code, consider `offset_from`.

🔬 This is a nightly-only experimental API. (`offset_to` #41079)

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 type.

# Examples

Basic usage:

    #![feature(offset_to)]
    #![allow(deprecated)]

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

####

`pub unsafe fn offset_from(self, origin: *const T) -> isize`

[src]

🔬 This is a nightly-only experimental API. (`ptr_offset_from` #41079)

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

####

`pub fn wrapping_offset_from(self, origin: *const T) -> isize`

[src]

🔬 This is a nightly-only experimental API. (`ptr_wrapping_offset_from` #41079)

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

####

`pub unsafe fn add(self, count: usize) -> *const T`

1.26.0
[src]

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 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:

    let s: &str = "123";
    let ptr: *const u8 = s.as_ptr();

    unsafe {
        println!("{}", *ptr.add(1) as char);
        println!("{}", *ptr.add(2) as char);
    }Run

####

`pub unsafe fn sub(self, count: usize) -> *const T`

1.26.0
[src]

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:

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

####

`pub fn wrapping_add(self, count: usize) -> *const T`

1.26.0
[src]

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

####

`pub fn wrapping_sub(self, count: usize) -> *const T`

1.26.0
[src]

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

####

`pub unsafe fn read(self) -> T`

1.26.0
[src]

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`, `write_bytes`, or `copy`). 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:

    let x = 12;
    let y = &x as *const i32;

    unsafe {
        assert_eq!(y.read(), 12);
    }Run

####

`pub unsafe fn read_volatile(self) -> T`

1.26.0
[src]

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`, `write_bytes`, or `copy`). Note that `*self = foo` counts as a use because it will attempt to drop the value previously at `*self`.

# Examples

Basic usage:

    let x = 12;
    let y = &x as *const i32;

    unsafe {
        assert_eq!(y.read_volatile(), 12);
    }Run

####

`pub unsafe fn read_unaligned(self) -> T`

1.26.0
[src]

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`, `write_bytes`, or `copy`). Note that `*self = foo` counts as a use because it will attempt to drop the value previously at `*self`.

# Examples

Basic usage:

    let x = 12;
    let y = &x as *const i32;

    unsafe {
        assert_eq!(y.read_unaligned(), 12);
    }Run

####

`pub unsafe fn copy_to(self, dest: *mut T, count: usize)`

1.26.0
[src]

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 `dest`, or prevent the contents of `self` from being dropped or used.

# Examples

Efficiently create a Rust vector from an unsafe buffer:

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

####

`pub unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize)`

1.26.0
[src]

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:

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

####

`pub fn align_offset(self, align: usize) -> usize`

[src]

🔬 This is a nightly-only experimental API. (`align_offset` #44488)

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.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
    }Run

###

`impl<T> *mut T where T: ?Sized,`

[src]

####

`pub fn is_null(self) -> bool`

[src]

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());Run

####

`pub 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);
        }
    }Run

####

`pub unsafe fn offset(self, count: isize) -> *mut T`

[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 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().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));
    }Run

####

`pub 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`). 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]);Run

####

`pub 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]".Run

####

`pub fn offset_to(self, other: *const T) -> Option<isize>`

[src]

Deprecated since 1.27.0

: Replaced by `wrapping_offset_from`, with the opposite argument order. If you're writing unsafe code, consider `offset_from`.

🔬 This is a nightly-only experimental API. (`offset_to` #41079)

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 type.

# Examples

Basic usage:

    #![feature(offset_to)]
    #![allow(deprecated)]

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

####

`pub unsafe fn offset_from(self, origin: *const T) -> isize`

[src]

🔬 This is a nightly-only experimental API. (`ptr_offset_from` #41079)

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

####

`pub fn wrapping_offset_from(self, origin: *const T) -> isize`

[src]

🔬 This is a nightly-only experimental API. (`ptr_wrapping_offset_from` #41079)

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

####

`pub unsafe fn add(self, count: usize) -> *mut T`

1.26.0
[src]

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 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:

    let s: &str = "123";
    let ptr: *const u8 = s.as_ptr();

    unsafe {
        println!("{}", *ptr.add(1) as char);
        println!("{}", *ptr.add(2) as char);
    }Run

####

`pub unsafe fn sub(self, count: usize) -> *mut T`

1.26.0
[src]

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:

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

####

`pub fn wrapping_add(self, count: usize) -> *mut T`

1.26.0
[src]

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

####

`pub fn wrapping_sub(self, count: usize) -> *mut T`

1.26.0
[src]

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

####

`pub unsafe fn read(self) -> T`

1.26.0
[src]

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`, `write_bytes`, or `copy`). 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:

    let x = 12;
    let y = &x as *const i32;

    unsafe {
        assert_eq!(y.read(), 12);
    }Run

####

`pub unsafe fn read_volatile(self) -> T`

1.26.0
[src]

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`, `write_bytes`, or `copy`). Note that `*self = foo` counts as a use because it will attempt to drop the value previously at `*self`.

# Examples

Basic usage:

    let x = 12;
    let y = &x as *const i32;

    unsafe {
        assert_eq!(y.read_volatile(), 12);
    }Run

####

`pub unsafe fn read_unaligned(self) -> T`

1.26.0
[src]

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`, `write_bytes`, or `copy`). Note that `*self = foo` counts as a use because it will attempt to drop the value previously at `*self`.

# Examples

Basic usage:

    let x = 12;
    let y = &x as *const i32;

    unsafe {
        assert_eq!(y.read_unaligned(), 12);
    }Run

####

`pub unsafe fn copy_to(self, dest: *mut T, count: usize)`

1.26.0
[src]

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:

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

####

`pub unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize)`

1.26.0
[src]

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:

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

####

`pub unsafe fn copy_from(self, src: *const T, count: usize)`

1.26.0
[src]

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:

    unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> {
        let mut dst: Vec<T> = Vec::with_capacity(elts);
        dst.set_len(elts);
        dst.as_mut_ptr().copy_from(ptr, elts);
        dst
    }Run

####

`pub unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize)`

1.26.0
[src]

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:

    unsafe fn from_buf_raw<T: Copy>(ptr: *const T, elts: usize) -> Vec<T> {
        let mut dst: Vec<T> = Vec::with_capacity(elts);
        dst.set_len(elts);
        dst.as_mut_ptr().copy_from_nonoverlapping(ptr, elts);
        dst
    }Run

####

`pub unsafe fn drop_in_place(self)`

1.26.0
[src]

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.

####

`pub unsafe fn write(self, val: T)`

1.26.0
[src]

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:

    let mut x = 0;
    let y = &mut x as *mut i32;
    let z = 12;

    unsafe {
        y.write(z);
        assert_eq!(y.read(), 12);
    }Run

####

`pub unsafe fn write_bytes(self, val: u8, count: usize)`

1.26.0
[src]

Invokes memset on the specified pointer, setting `count * size_of::<T>()` bytes of memory starting at `self` to `val`.

# Examples

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

####

`pub unsafe fn write_volatile(self, val: T)`

1.26.0
[src]

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:

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

####

`pub unsafe fn write_unaligned(self, val: T)`

1.26.0
[src]

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 `self`. Semantically, `self` is moved into the location pointed to by `val`.

This is appropriate for initializing uninitialized memory, or overwriting memory that has previously been `read` from.

# Examples

Basic usage:

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

####

`pub unsafe fn replace(self, src: T) -> T`

1.26.0
[src]

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`.

####

`pub unsafe fn swap(self, with: *mut T)`

1.26.0
[src]

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`.

####

`pub fn align_offset(self, align: usize) -> usize`

[src]

🔬 This is a nightly-only experimental API. (`align_offset` #44488)

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.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
    }Run

## Trait Implementations

###

`impl<T> Hash for *const T where T: ?Sized,`

[src]

####

`fn hash<H>(&self, state: &mut H) where H: Hasher,`

[src]

Feeds this value into the given [`Hasher`]. Read more

####

`fn hash_slice<H>(data: &[Self], state: &mut H) where H: Hasher,`

1.3.0
[src]

Feeds a slice of this type into the given [`Hasher`]. Read more

###

`impl<T> Hash for *mut T where T: ?Sized,`

[src]

####

`fn hash<H>(&self, state: &mut H) where H: Hasher,`

[src]

Feeds this value into the given [`Hasher`]. Read more

####

`fn hash_slice<H>(data: &[Self], state: &mut H) where H: Hasher,`

1.3.0
[src]

Feeds a slice of this type into the given [`Hasher`]. Read more

###

`impl<T> Pointer for *const T where T: ?Sized,`

[src]

####

`fn fmt(&self, f: &mut Formatter) -> Result<(), Error>`

[src]

Formats the value using the given formatter.

###

`impl<T> Pointer for *mut T where T: ?Sized,`

[src]

####

`fn fmt(&self, f: &mut Formatter) -> Result<(), Error>`

[src]

Formats the value using the given formatter.

###

`impl<T> Clone for *const T where T: ?Sized,`

[src]

####

`fn clone(&self) -> *const T`

[src]

Returns a copy of the value. Read more

####

`fn clone_from(&mut self, source: &Self)`

[src]

Performs copy-assignment from `source`. Read more

###

`impl<T> Clone for *mut T where T: ?Sized,`

[src]

####

`fn clone(&self) -> *mut T`

[src]

Returns a copy of the value. Read more

####

`fn clone_from(&mut self, source: &Self)`

[src]

Performs copy-assignment from `source`. Read more

###

`impl<T> Debug for *const T where T: ?Sized,`

[src]

####

`fn fmt(&self, f: &mut Formatter) -> Result<(), Error>`

[src]

Formats the value using the given formatter. Read more

###

`impl<T> Debug for *mut T where T: ?Sized,`

[src]

####

`fn fmt(&self, f: &mut Formatter) -> Result<(), Error>`

[src]

Formats the value using the given formatter. Read more

###

`impl<T> PartialOrd<*mut T> for *mut T where T: ?Sized,`

[src]

####

`fn partial_cmp(&self, other: &*mut T) -> Option<Ordering>`

[src]

This method returns an ordering between `self` and `other` values if one exists. Read more

####

`fn lt(&self, other: &*mut T) -> bool`

[src]

This method tests less than (for `self` and `other`) and is used by the `<` operator. Read more

####

`fn le(&self, other: &*mut T) -> bool`

[src]

This method tests less than or equal to (for `self` and `other`) and is used by the `<=` operator. Read more

####

`fn gt(&self, other: &*mut T) -> bool`

[src]

This method tests greater than (for `self` and `other`) and is used by the `>` operator. Read more

####

`fn ge(&self, other: &*mut T) -> bool`

[src]

This method tests greater than or equal to (for `self` and `other`) and is used by the `>=` operator. Read more

###

`impl<T> PartialOrd<*const T> for *const T where T: ?Sized,`

[src]

####

`fn partial_cmp(&self, other: &*const T) -> Option<Ordering>`

[src]

This method returns an ordering between `self` and `other` values if one exists. Read more

####

`fn lt(&self, other: &*const T) -> bool`

[src]

This method tests less than (for `self` and `other`) and is used by the `<` operator. Read more

####

`fn le(&self, other: &*const T) -> bool`

[src]

This method tests less than or equal to (for `self` and `other`) and is used by the `<=` operator. Read more

####

`fn gt(&self, other: &*const T) -> bool`

[src]

This method tests greater than (for `self` and `other`) and is used by the `>` operator. Read more

####

`fn ge(&self, other: &*const T) -> bool`

[src]

This method tests greater than or equal to (for `self` and `other`) and is used by the `>=` operator. Read more

###

`impl<T> Ord for *mut T where T: ?Sized,`

[src]

####

`fn cmp(&self, other: &*mut T) -> Ordering`

[src]

This method returns an `Ordering` between `self` and `other`. Read more

####

`fn max(self, other: Self) -> Self`

1.21.0
[src]

Compares and returns the maximum of two values. Read more

####

`fn min(self, other: Self) -> Self`

1.21.0
[src]

Compares and returns the minimum of two values. Read more

###

`impl<T> Ord for *const T where T: ?Sized,`

[src]

####

`fn cmp(&self, other: &*const T) -> Ordering`

[src]

This method returns an `Ordering` between `self` and `other`. Read more

####

`fn max(self, other: Self) -> Self`

1.21.0
[src]

Compares and returns the maximum of two values. Read more

####

`fn min(self, other: Self) -> Self`

1.21.0
[src]

Compares and returns the minimum of two values. Read more

###

`impl<T> Eq for *const T where T: ?Sized,`

[src]

###

`impl<T> Eq for *mut T where T: ?Sized,`

[src]

###

`impl<T, U> CoerceUnsized<*const U> for *const T where T: Unsize<U> + ?Sized, U: ?Sized,`

[src]

###

`impl<T, U> CoerceUnsized<*const U> for *mut T where T: Unsize<U> + ?Sized, U: ?Sized,`

[src]

###

`impl<T, U> CoerceUnsized<*mut U> for *mut T where T: Unsize<U> + ?Sized, U: ?Sized,`

[src]

###

`impl<T> PartialEq<*mut T> for *mut T where T: ?Sized,`

[src]

####

`fn eq(&self, other: &*mut T) -> bool`

[src]

This method tests for `self` and `other` values to be equal, and is used by `==`. Read more

####

`#[must_use] fn ne(&self, other: &Rhs) -> bool`

[src]

This method tests for `!=`.

###

`impl<T> PartialEq<*const T> for *const T where T: ?Sized,`

[src]

####

`fn eq(&self, other: &*const T) -> bool`

[src]

This method tests for `self` and `other` values to be equal, and is used by `==`. Read more

####

`#[must_use] fn ne(&self, other: &Rhs) -> bool`

[src]

This method tests for `!=`.

###

`impl<T> Copy for *const T where T: ?Sized,`

[src]

###

`impl<T> Copy for *mut T where T: ?Sized,`

[src]

###

`impl<T> !Sync for *mut T where T: ?Sized,`

[src]

###

`impl<T> !Sync for *const T where T: ?Sized,`

[src]

###

`impl<T> !Send for *const T where T: ?Sized,`

[src]

###

`impl<T> !Send for *mut T where T: ?Sized,`

[src]

###

`impl<T: RefUnwindSafe + ?Sized> UnwindSafe for *const T`

1.9.0
[src]

###

`impl<T: RefUnwindSafe + ?Sized> UnwindSafe for *mut T`

1.9.0
[src]

# Help

## Keyboard Shortcuts

`?`
  Show this help dialog
`S`
  Focus the search field
`↑`
  Move up in search results
`↓`
  Move down in search results
`↹`
  Switch tab
`⏎`
  Go to active search result
`+`
  Expand all sections
`-`
  Collapse all sections

## Search Tricks

Prefix searches with a type followed by a colon (e.g. `fn:`) to restrict the search to a given type.

Accepted types are: `fn`, `mod`, `struct`, `enum`, `trait`, `type`, `macro`, and `const`.

Search functions by type signature (e.g. `vec -> usize` or `* -> vec`)

Search multiple things at once by splitting your query with comma (e.g. `str,u8` or `String,struct:Vec,test`)