4 ms·

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 r

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.

blep_ 4y ago
Most definitions of memory safety include not crashing.
- verdagon 4y ago
  What about bounds checking on array access, like most memory safe languages?
- WalterBright 4y ago
  Having the program exit when a memory safety fault is detected is entirely safe.
- dukc 4y ago
  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.
AlotOfReading 4y ago
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 .
- verdagon 4y ago
  Reasonable answers, thank you! I wonder how D might address that.
oconnor663 4y ago
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/ https://lwn.net/Articles/342330/
- dukc 4y ago
  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.
Smaug123 4y ago
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).

blep_ 4y ago

Most definitions of memory safety include not crashing.

verdagon 4y ago
What about bounds checking on array access, like most memory safe languages?
WalterBright 4y ago
Having the program exit when a memory safety fault is detected is entirely safe.
dukc 4y ago
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.

AlotOfReading 4y ago

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 .

verdagon 4y ago
Reasonable answers, thank you! I wonder how D might address that.

oconnor663 4y ago

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/ https://lwn.net/Articles/342330/

dukc 4y ago
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.

Smaug123 4y ago

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).