4 ms·

They're definitely not the same at all. Dereferencing a null pointer in C and C++ is undefined behavior. You can read more about it here: https://rootkits.xyz/b

They're definitely not the same at all. Dereferencing a null pointer in C and C++ is undefined behavior. You can read more about it here: https://rootkits.xyz/blog/2018/01/kernel-null-pointer-dereference/ https://rootkits.xyz/blog/2018/01/kernel-null-pointer-derefe... In rust an unwrap of a None is defined and memory safe.

The_rationalist 6y ago
I don't understand the practical consequence, it will make your program panic and therefore stop which is order of magnitude worse than throwing a null pointer exception, can you imagine your long running application (e.g a server) stopping in production..
- saagarjha 6y ago
  Almost no code can correctly reason about a stray null pointer, and usually they result in strange auxiliary crashes or data corruption. Loudly crashing is often the best choice, even in production.
- maccard 6y ago
  you can likely use SEH/Signals in zig to catch the panic and resume. In C++, you'll be lucky if you throw a nullptr exception. It's undefined behaviour, and it's often exploited by compilers for optimization. Here's a super simple example [0] showing how the compiler makes assumptions and generates a very unexpected result. [0] https://gcc.godbolt.org/z/7159jGhex https://gcc.godbolt.org/z/7159jGhex
- withoutboats2 6y ago
  Java's NPE is not at all the same thing as the undefined behavior of dereferencing a null pointer in C (or Zig in release mode). In fact its the same exact thing as calling unwrap. Your Java server's NPE is not bringing down the entire server because the exception is caught somewhere. The same can be done in Rust (and is, by many frameworks), where panics are caught before they crash the entire application.
  - yellowapple 6y ago
    > or Zig in release mode My understanding is that Zig doesn't allow pointers to be null in the first place (regardless of release mode) unless you're 1) manually creating a pointer from an integer or 2) interfacing with C, and in both of those cases all bets are already off anyway (as they would be in Rust). The only "supported" options outside of that would be a non-null pointer or None.
- staticassertion 6y ago
  > I don't understand the practical consequence Well I did link to a blog post that explains this, so I feel like it's sort of on you at this point. But I guess the short answer is that in Rust you know exactly what 'unwrap' will do on a None, and in C/C++ you can't. > can you imagine your long running application (e.g a server) stopping in production.. Yes. It happens all the time, and in fact it is inevitable. Far better than the program misbehaving, which is what undefined behavior leads to. In fact if you're building a serious, production service, you might want to skip panicking altogether and just kill the process.
- gnulinux 6y ago
  If my code derefrences null, I want it to panic even in production. Assuming your server will never fail is very dangerous. oom killer can just kill your process for unrelated reasons to your server.
- quietbritishjim 6y ago
  The main difference[1] between a panic and undefined behaviour, including a null pointer access in C/C++, is that undefined behaviour might not crash. It's tempting to equate "undefined behaviour" with SIGSEGV but it doesn't have to be so. The undefined behaviour is even allowed to travel back in time to an earlier line of code, so long as the compiler is able to prove that it would have eventually invoked that undefined behaviour (e.g. it can prove that it would later dereference that null pointer). So however bad it might be for your production server to crash, imagine how much worse it might be for it to appear to continue working while it actually corrupts memory and database entries, or an attacker uses it as an exploit to read other users' information, or whatever else. At least when it crashes you can detect that with your health monitoring and potentially start it back up (if the same problem doesn't cause it to immediately crash again in a loop, of course). [1] A secondary difference is that it is possible to catch Rust panics in an analogous way to catching C++ exceptions. This isn't encouraged and might not even work (if they've been turned into calls to abort() at compile time). The fact that they're not undefined behaviour is the big one.

The_rationalist 6y ago

I don't understand the practical consequence, it will make your program panic and therefore stop which is order of magnitude worse than throwing a null pointer exception, can you imagine your long running application (e.g a server) stopping in production..

saagarjha 6y ago
Almost no code can correctly reason about a stray null pointer, and usually they result in strange auxiliary crashes or data corruption. Loudly crashing is often the best choice, even in production.
maccard 6y ago
you can likely use SEH/Signals in zig to catch the panic and resume. In C++, you'll be lucky if you throw a nullptr exception. It's undefined behaviour, and it's often exploited by compilers for optimization. Here's a super simple example [0] showing how the compiler makes assumptions and generates a very unexpected result. [0] https://gcc.godbolt.org/z/7159jGhex https://gcc.godbolt.org/z/7159jGhex
withoutboats2 6y ago
Java's NPE is not at all the same thing as the undefined behavior of dereferencing a null pointer in C (or Zig in release mode). In fact its the same exact thing as calling unwrap. Your Java server's NPE is not bringing down the entire server because the exception is caught somewhere. The same can be done in Rust (and is, by many frameworks), where panics are caught before they crash the entire application.
- yellowapple 6y ago
  > or Zig in release mode My understanding is that Zig doesn't allow pointers to be null in the first place (regardless of release mode) unless you're 1) manually creating a pointer from an integer or 2) interfacing with C, and in both of those cases all bets are already off anyway (as they would be in Rust). The only "supported" options outside of that would be a non-null pointer or None.
staticassertion 6y ago
> I don't understand the practical consequence Well I did link to a blog post that explains this, so I feel like it's sort of on you at this point. But I guess the short answer is that in Rust you know exactly what 'unwrap' will do on a None, and in C/C++ you can't. > can you imagine your long running application (e.g a server) stopping in production.. Yes. It happens all the time, and in fact it is inevitable. Far better than the program misbehaving, which is what undefined behavior leads to. In fact if you're building a serious, production service, you might want to skip panicking altogether and just kill the process.
gnulinux 6y ago
If my code derefrences null, I want it to panic even in production. Assuming your server will never fail is very dangerous. oom killer can just kill your process for unrelated reasons to your server.
quietbritishjim 6y ago
The main difference[1] between a panic and undefined behaviour, including a null pointer access in C/C++, is that undefined behaviour might not crash. It's tempting to equate "undefined behaviour" with SIGSEGV but it doesn't have to be so. The undefined behaviour is even allowed to travel back in time to an earlier line of code, so long as the compiler is able to prove that it would have eventually invoked that undefined behaviour (e.g. it can prove that it would later dereference that null pointer). So however bad it might be for your production server to crash, imagine how much worse it might be for it to appear to continue working while it actually corrupts memory and database entries, or an attacker uses it as an exploit to read other users' information, or whatever else. At least when it crashes you can detect that with your health monitoring and potentially start it back up (if the same problem doesn't cause it to immediately crash again in a loop, of course). [1] A secondary difference is that it is possible to catch Rust panics in an analogous way to catching C++ exceptions. This isn't encouraged and might not even work (if they've been turned into calls to abort() at compile time). The fact that they're not undefined behaviour is the big one.