Hacker News Reader

Comment by kibwen | Hacker News Reader

For reference, the following actions are what are enabled within `unsafe` blocks in Rust:

1. Dereferencing raw pointers (a.k.a. "unsafe" pointers). Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

2. Calling a Rust function that has been marked with the entirely-optional `unsafe` keyword.

3. Calling an external function via the C FFI, all of which are automatically considered unsafe.

View on HN

>Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

Sure there is. Passing around multiple pointers can result in a double free and then the dangerous dereference can happen. I'm guessing the developer must be careful when writing unsafe blocks to make sure this doesn't happen.

but they are safe until you decide to do that deferencing, otherwise they're just uint_ptrs really.

Unsafe behaviours with raw pointers:

  - dereferencing
  - arithmetic (implemented as ptr.offset(number) in the stdlib), 
    since it is undefined behaviour for LLVM to move a pointer to
    point outside* of the object that it came from originally 
    (even without deferencing)

Everything else is OK. (Although the only other thing possible is passing it around as "black box" value.)

*One byte past the end is ok.

Don't points 2 & 3 together imply that anything that uses built-ins, which I assume are implemented with C FFI, is `unsafe`?

I'm not 100% sure exactly what you mean by 'built-ins', but Rust is almost entirely written in Rust. I don't think there's anything major implemented via C FFI in the compiler itself.

Just to clarify, using a `unsafe` block in a function does NOT mean that you have to tag that function as unsafe.

No, “unsafe” means “evaluate this unsafe block as though it were safe”. This enables Modula-style safe interfaces for unsafe implementations.

Reply on news.ycombinator.com