Блог*

#prog #rust

Очередное напоминание, что Rust не является просто улучшенным C и что ссылки не являются просто продвинутой версией указателей.

Рассмотрим вот такой код, полностью нормальный с точки зрения сишника:

fn main() {
    let a: [i32; 2] = [0, 1];
    let ptr: *const _ = &a[0];
    let x_ptr = unsafe { ptr.add(1) };
    let x = unsafe { *x_ptr };
    println!("{x}");
}

Тут мы получаем указатель на элементы массива через ссылку на его первый элемент — как это часто делают в C. Если этот код скомпилировать и запустить, то программа напечатает 1, как и ожидается. Но, строго говоря, он не обязан этого делать! Потому что в этой программе есть UB. Действительно, если на этом коде запустить miri, то вот какой будет результат:

error: Undefined Behavior: attempting a read access using <3091> at alloc1664[0x4], but that tag does not exist in the borrow stack for this location
 --> src/main.rs:5:22
  |
5 |     let x = unsafe { *x_ptr };
  |                      ^^^^^^
  |                      |
  |                      attempting a read access using <3091> at alloc1664[0x4], but that tag does not exist in the borrow stack for this location
  |                      this error occurs as part of an access at alloc1664[0x4..0x8]
  |
  = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
  = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <3091> was created by a SharedReadOnly retag at offsets [0x0..0x4]
 --> src/main.rs:3:25
  |
3 |     let ptr: *const _ = &a[0];
  |                         ^^^^^
  = note: BACKTRACE:
  = note: inside `main` at src/main.rs:5:22

Ошибка довольно многословная, но суть её состоит в том, что указатель на первый элемент сформирован из ссылки на первый элемент массива и потому имеет право обращаться только к этому конкретному i32 и не может быть использован для того, чтобы обращаться дальше по памяти. Надо отметить, что сама операция ptr.add(1) UB не вызывает — в документации прямо сказано, что при помощи неё можно получить указатель "one byte past the end of the same allocated object". В данном случае именно такой указатель и будет сформирован, ибо этим самым allocated object является отдельный i32, а не массив целиком.

Если мы попытаемся обмануть компилятор и взять сырой указатель:

    ...
    let ptr = core::ptr::addr_of!(a[0]);
    ...

, то у нас ничего не выйдет: miri будет так же ругаться, поскольку операция индексации берёт ссылку и фактически ссылку и возвращает.

Как же поступить правильно? Можно сформировать указатель на элемент из сырого указателя на сам массив:

let ptr = core::ptr::addr_of!(a) as *const i32;

Но это в основном имеет смысл, когда по каким-то причинам нет возможности использовать ссылку на массив. Если же есть, то проще использовать специальный метод для это, as_ptr (который, кстати, тут работает за счёт deref coercion из ссылки на массив в ссылку на слайс):

let ptr = a.as_ptr();

В любом случае, при использовании одного из этих двух методов miri не считает код содержащим UB.

doc.rust-lang.org

pointer - Rust

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

🔥7👍1😱1

746 views20:11