Hacker News Reader

Comment by Smaug123 | Hacker News Reader

"int* can point to the null address, but this is generally not a memory safety problem because the null address is protected by the operating system. Any attempt to dereference it would crash the program before any memory corruption can happen."

This is the most cursed definition of "memory safe" I have ever seen. I think the article would benefit from a link to https://dlang.org/spec/memory-safe-d.html explaining explicitly that this is actually what you intended to write, because it made me do a double-take and a Google when I read it.

View on HN

Mind explaining why it's a bad thing to rely on the OS's built-in protections around nulls?

I'm familiar with a few arguments w.r.t. large structs and arrays running past the protected pages, but they seem pretty trivially solvable. Would love to hear why it's a cursed definition.

Most definitions of memory safety include not crashing.

What about bounds checking on array access, like most memory safe languages?

Having the program exit when a memory safety fault is detected is entirely safe.

Nope. Memory safety means no undefined behaviour. Crashing is defined behaviour. Indeed, at least in the D philosophy it is better to crash than to just do something and continue when a bug is detected. If that were not the case, assertions in released code would be total humbug.

Now, detecting such errors statically at compile time is still valuable where it is practical. But it's common knowledge that no language guarantees no bugs. It follows that a complete "no crashing" guarantee is not even desirable, let alone part of a memory safety guarantee.

Well for one the code might be running in kernel space, so a null pointer access could very well be fatal. There are also use cases that D supports (e.g. certain bare metal arm targets) where the all-bits-zero pointer is validly addressable and contains Important Stuff.

Those protections are there as last ditch safety measures. You shouldn't rely on them .

Reasonable answers, thank you! I wonder how D might address that.

I'm not sure about D's situation specifically, but one issue with null ptr dereferences in C, C++, and (unsafe) Rust is that they're UB by definition, so you're at the mercy of the optimizer if it can ever prove that you're dereferencing null. This has led to some interesting security issues in the past: https://lwn.net/Articles/342330/

An optimiser may not treat null-dereferencing D code as undefined behaviour. It must either error at compile time (if it can prove the dereference would be null no matter what), crash at runtime, or derefer the null address, which also results in a crash.

Exactly - the language isn't memory-safe. Instead it's effectively (implicitly!) relying on the fact that it runs on an abstract machine that has certain memory-safety properties. By contrast, a memory-safe language like C# is defined to be running on a memory-safe abstraction (the CLR, or more generally anything that faithfully implements the Microsoft intermediate language), while a memory-safe language like Rust either proves behaviour via the type system (no null pointers, no use after free) or inserts runtime checks (no out-of-bounds array accesses, panic on out-of-memory).

Reply on news.ycombinator.com