Why is dereferencing a null raw pointer undefined behaviour?

0
votes

The Rust reference states:

  • The following is a list of behavior which is forbidden in all Rust code, including within unsafe blocks and unsafe functions:
    • Dereferencing a null/dangling raw pointer

This question is solely about the null part. There's no inherent reason to require that a definite but unknown address in an address space be made inaccessible. That's my thesis (it's what most implementations of the null pointer do), so why is Rust following in these footsteps since it seems merely ancient C cruft?

I've heard several stories (example, another, another) in my career where there was a need to access such a pointer, so why allow the spec (and hence, implementations) to get in the way again?

There's assembly output and a lot of context in the C++ Reddit thread from which this question stems. It was also brought up in this Rust Reddit thread.

Despite the many "war stories" referred above, what is really upsetting for me is not in that realm, but more on the abstract one: making address space access (which is delivered by the hardware) non uniform from a language's specification, a priori to all hardware/OS/architectures it may ever be used for.

1
nullrustundefined-behavior
Note that (even in C), a null pointer is not necessary a pointer whose value is 0. If the address 0 was a valid value for a pointer on some platform, it could use any other placeholder for its null pointer. – mcarton
@mcarton I try hard to avoid this misconception when putting up the question, and fail, because each time someone comes to point it. And the endless discussion starts over null pointer not being the value 0. Sorry but the question is not about it, it tries to avoid this interpretation. – pepper_chico
You've edited your question to add “a priori to all hardware/OS/architectures it may ever be used for” but that's the point of the null pointer: it is not set a priori for all hardware/OS/architectures. It is set a priori for a hardware/OS/architecture, but the value can be any value that does not make sense to dereference on that hardware/OS/architecture. – mcarton
@mcarton I edited it in several places trying to avoid that line of thought further. The question is not about which value, whatever it is, the issue is on why require any, for that. – pepper_chico
@mcarton the address space is set irregular upfront on the language spec (for which reason this question is being asked). It cares that any other address except one (null, whatever it is) can be accessed without limitations imposed by the language (and for consequence the compiler). The platform detail that there will always be an address that can be used for this task is just an assumption, and as such, why have this assumption (it seems completely disposable)? – pepper_chico

1 Answers

3
votes

The null pointer is special-cased elsewhere in the language already. For example, Option<Box<T>> (where T: Sized) will use only one word, not two, because a null pointer is used to represent None. Disallowing code that follows null pointers is consistent with this idea.

In a broader sense, Rust has not given as much attention to supporting exotic architectures as C. This is not out of malice, but merely a matter of priorities during its design. The language was built for a modern web browser, after all – an application which runs in user mode on x86 or ARM. That's not the kind of use case where these issues would come up. Perhaps if someone brought it up pre-1.0 it could have gone differently.