Can a language allow raw pointer dereferencing while preserving memory safety?

Question

In Rust, creating a raw pointer is allowed in safe code (i.e. outside of unsafe blocks), but then dereferencing it is unsafe:

let my_num_ptr: *const i32 = &my_num;
let value: i32 = unsafe {*my_num};

Undefined behaviour would only occur in a program which both creates and incorrectly dereferences a raw pointer. So long as one of these operations is only allowed in an unsafe block, memory safety can be guaranteed for programs which have no unsafe blocks.

What if, instead of requiring an unsafe block for the dereference operation, it is instead required for the creation of the raw pointer? For example:

let i: const *u32 = unsafe {&4};
let b = *i;

Or even:

let i: mut *u32 = unsafe {&mut 8};
*i = 5;

In this hypothetical language, operations which create a raw pointer are unsafe (and must only occur in unsafe blocks), but dereferencing them is allowed in safe code, on the basis that it's the programmer's responsibility to make sure when creating the raw pointer that the pointed-to value will stay alive at that memory address for long enough. Is this sound? Would there be any advantages to doing it this way instead of the Rust way?

---

Note that in Rust, a unsafe block does not mean that the entire program is unsafe, just that there are invariants the compiler can't check, so the programmer is responsible for them. If the programmer has made sure the rules are followed, it's perfectly safe.

In Rust currently, it is undefined behavior to dereference a null pointer, a unaligned pointer, or one that points to uninitialized memory. I'm suggesting that the undefined behavior happens when constructing such a pointer instead.

Answer 1

The trivial answer is yes, it's sound so long as the programmer keeps up their end of the bargain and doesn't create and then incorrectly dereference a raw pointer; and so long as one of those two operations is considered "unsafe" and must be put in an unsafe block, then programs with no unsafe blocks cannot violate memory safety in this way.

But I think that isn't a satisfactory answer to the question, because it doesn't address what burden is placed on the programmer to ensure that they use this pair of operations together safely.

In Rust currently, it is undefined behavior to dereference a null pointer, a unaligned pointer, or one that points to uninitialized memory.

I think the last point needs to be addressed. "Uninitialised memory" doesn't just mean memory which hasn't had a valid value written to it. For our purposes here, memory is also uninitialised if the allocation has been freed before the dereference occurs (i.e. use-after-free), even if it was initialised before it was freed.

I mention this not because it should be new information, but to highlight what I think is a significant problem with your idea. You can guarantee when the pointer is created that it is non-null, correctly-aligned and that the data it points to is initialised; but you can't guarantee at the creation-site that it will stay initialised for long enough. (Well, you could bind the lifetime of the allocation to the lexical scope it's allocated in, but that gives you the borrow checker, not raw pointers.)

To avoid use-after-free without a borrow checker, it is the programmer's responsibility to check each time the pointer is dereferenced that the dereference can occur only after initialisation and before freeing. That is, the programmer's burden is to ensure this at each dereference site. So it makes more sense to put the unsafe block around the dereference sites (as Rust does), because that's where your attention needs to be when you're checking that the pointer is being used correctly.

In contrast, if there is just one unsafe block where the pointer is created, then there is potentially a large amount of code outside of that block which also needs to be audited, but no "warning signs" telling you to look there.

Answer 2

In Rust currently, it is undefined behavior to dereference a null pointer, a unaligned pointer, or one that points to uninitialized memory.

It's also undefined behaviour to.

1. Access a block of memory after it has been deallocated.
2. Violate the aliasing/mutability rules.

The first is bad, it essentially means that any pointer created based on a memory with non-static lifetime is a time-bomb.

The second though is arguably worse. Consider for example the following code.

fn main() {
    unsafe {
        let mut a : String = "hello world".to_owned();
        let b : * mut String = &mut a;
        let c = (*b).as_str();
        *b = "crash and burn baby".to_owned();
        print!("{}",c);
    }
}

Normally deriving a &str from a String is safe. It's safe because not only is the String gauranteed to outlive the &str, but the String is guaranteed to remain in a stable state for as long as the &str exists.

In this case though, while the String does outlive the str it does not remain in a stable state for the lifetime of the str. When the String is reassigned to a new value, the str derived from it becomes a dangling reference!

Or to put it another way, no matter how much care is taken by the creator of a *mut String, the code derefencing that *mut String can invoke a serious violation of memory safety.

Answer 3

A language with a pointer type that disallows pointer arithmetic, and a "fat pointer" type which includes a base address, range, and offset, could uphold memory safety if the only "unsafe" operations were the formation of the above pointer types, in contexts where the address ranges associated with pointers would remain usable for the duration of the program. Only address ranges that were not otherwise used by the application could have such pointers constructed to them, and any special functions that generated such pointers without being marked "unsafe" would need to ensure that they only returned pointers to storage meeting the aforementioned criteria, but many tasks that would otherwise require raw memory access could be accomplished even with such restricted semantics. For example, a system which uses a memory-mapped display may be able to allow "safe" application code direct access to the display memory if it will be entitled to have exclusive access to that memory for its lifetime.

Answer 4

The secret is that most of the practical memory safety comes from bounds checking of arrays. So if you have that you get 80 % of the benefit while still allowing use of pointers. Odin is a good example of this in practice, http://odin-lang.org/.