Hacker News Reader

Comment by quietbritishjim | Hacker News Reader

From the table:

> null pointer dereference ... [C] none; [Zig] runtime; [Rust] runtime

Assuming this is talking normal "safe" Rust, I think I disagree with this. The Rust analogue of a pointer in safe code is a reference, not a Rust pointer, and these can't null at all. You could use an Option<> of a reference, and Rust will internally use null to represent the None (empty) case, but an attept to use the option without checking for None will result in an error at compile time, not runtime. Yes you could convert that into a runtime error, but if it was an error condition for that variable to be None then (depending on the context) you could choose not to use an Option at all and then it would be a compile-time error at the call site to attempt to put None into it.

I don't think I understand what is meant by "type confusion". Surely this would also cause compile-time errors? Even C++ would give compile time errors for this unless you use a cast! (C, unlike C++, lets you implicitly convert from void* to any other pointer type so you don't need a cast to get pointer confusion.) Could someone think of an example of what might be meant here, and how it would cause a runtime error?

View on HN

> I don't think I understand what is meant by "type confusion".

Accessing a memory location with one type as if it's another. In C or C++ it's usually because you accessed a union without checking a tag somewhere else.

One classic way this happens is in an interpreter where you have a big enum for all the different possible data types:

https://github.com/MaterializeInc/materialize/blob/1b9b3cfab...

And then in various builtin functions you expect particular types:

https://github.com/MaterializeInc/materialize/blob/main/src/...

In rust and zig this code will produce a runtime error if you screw up, but in c it's easy to forget to check the tag and then you get UB. Similarly unwrap is checked in rust and zig but the equivalent in c - dereferencing a pointer that you are pretty sure is not null - is not.

Of course rust and zig both have support for c-style unions too, but they're not the first thing people reach for.

Thanks for answering. As I said in another comment (in reply to another tsimionescu who suspected that's what you meant), I maintain that this is a compile time error. Yes, one usage is to panic if the contents of the enum is not what you expect, in which case an unexpected type causes a runtime error. But that is the programmer choosing to deal with it way.

Fundamentally in the language, mismatching type is a compile time error. In many situations it's feasible to exhaustively match and deal with all possible cases of an enum (which then causes a compile time error if you try to reference one of the other inner types from within the "wrong" case). Where one particular case is expected, you can often ensure through the type system that this case is the only possibility by using that individual type directly rather than passing that enum around. In some situations its not feasible or it is feasible but the extra faff isn't worth the reward - but even then I don't think it justifies saying that the type confusion is detected in runtime in a comparison of languages.

> In rust and zig this code will produce a runtime error if you screw up, but in c it's easy to forget to check the tag and then you get UB.

As pointed out elsewhere, somewhat surprisingly, this is not UB in C, though it is in C++. In C it is merely unspecified behavior, but perfectly safe if intended.

My bad, should have verified first.

Another (much smaller) detail is that signed overflow in C is undefined (and iirc GCC takes advantage of that when optimizing) but signed overflow in Rust is precisely defined to error in debug mode and wrap in release mode.

And unsigned overflow is also error-in-debug, overflow-in-release with Rust. If you want wrapping arithmetic, you have to ask for it. In C, unsigned overflow always wraps, so even though you can compile with overflow checks, there's no way to distinguish unsigned arithmetic that is supposed to vs not supposed to wrap.

Sounds sensible. To quote John Regehr:

> Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap.

• https://blog.regehr.org/archives/1401

I actually dislike Rust's "wrap in production" default, tbh. It strikes a strange balance: "we care about performance in release mode but we are also going to check and make sure this code does specific things on overflow".

I'm not sure I follow. In release mode it does the most performant thing by default. In debug mode and tests it catches potential problems with using this default.

Either way there are explicit methods for doing wrapped, checked or saturating operations in every mode.

Undefined behavior on overflow is always the most performant, followed closely by "the result is unspecified". Wrapping is less performant because it often forces the implementation to actually wrap if the behavior is observable, which might be extra work (e.g. i32) or interfere with loop optimizations.

Undefined behaviour isn't an option for Safe Rust, where the impossibility of invoking undefined behaviour is the whole point. Non-deterministic unspecified values aren't in keeping with the Safe Rust philosophy either.

I imagine throw-on-overflow is slower than wrap-on-overflow.

C# can be configured to throw an exception when an int is overflowed, [0] but this behaviour isn't the default and is rarely used (typically it uses wrap-on-overflow). I imagine it might have a significant performance impact, but I'm not sure.

In a language like SPARK Ada, intended for formal verification, you can insist upon a rigorous proof that unintended overflow can never occur. That isn't an option for Safe Rust, at least not without significant breakthroughs in tooling.

[0] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Perhaps, but I often know via information not available to the compiler (it might be to a SPARK proof) that overflow won't happen and I don't want to check for it.

That option's available in Rust on a per opration basis if you want it, it's just not the default

Programmers can't be trusted to do this kind of free-form reasoning correctly, as attested by the unending stream of security vulnerabilities arising from undefined behaviour in C and C++ codebases.

The push for safe languages is motivated by pragmatism, not theoretical purity.

The push back that performance matters in the real world still exists. I want a secure language, but I don't have enough spare CPU for some

The performance of modern Rust is competitive with C++.

Which is why I told my boss I want some time to play with rust to see how it works in our real world.

> I imagine it might have a significant performance impact,

It depends on the CPU: MIPS has(had if you consider MIPS dead) some integer operations which trapped in case of integer overflow AFAIK the 'trapping operations' were as fast as the non-trapping operations (when no overflow occurred of course).

Unfortunately even though RISC-V is MIPS successor, it doesn't have those trapping operations :-(

I must admit I don't understand why no modern CPU ISA has these trapping instructions: explicit checks have an 'instruction cache cost', so users won't enable them which reduces security..

Zero UB in safe code is a core design constraint of Rust so I think it makes sense. Having integer overflow being implementation defined would sound more logical to me than the current behavior, but maybe there are arguments against it also.

Introducing implementation-defined behaviour would undermine the advantages of Safe Rust. If I understand the goals of the Safe Rust project correctly, it aims to be a truly safe language, like Java or JavaScript. This means it must have no undefined behaviour, and beyond that, it should be as close to 'totally defined' as possible, without leaving program behaviour up to the particular platform, which would open the door to subtle bugs. (Concurrency is an exception here, as it really can't be made to be deterministic. Floating point might be another.)

An obvious example: does this code result in a divide-by-zero? (I'll use C syntax.)

    int myInt = INT_MAX;
    ++myInt;
    int myOtherInt = 1000 / myInt;

If signed overflow is permitted to result in myInt holding zero, then we have a divide-by-zero. Not the kind of thing that should be left up to the particular platform.

The behaviour of your Java code does not change when you move it from a 32-bit x86 machine to a 64-bit ARM machine. That's part of the appeal of Java. The same should be true of Safe Rust.

To put that another way: Safe Rust is remarkable because of its ambition: to be a truly safe language, while also having excellent real-world performance. It seems to be succeeding in doing both, without trading off on performance (Java, Go, C#) or safety (C++, and even Ada). If it starts compromising on either dimension, it becomes 'just another language'.

To be clear, it actually is implementation defined. The rules are:

Integer overflow is a "program error." This case is handled by either "default" or "enabled" overflow checking:

* If checks are "enabled", then overflow must panic

* If checks are "default", then you'll get two's compliment wrapping

For implementations, if debug_assertions are enabled, then so must overflow checking be, unless the user specifically requests otherwise.

According to these rules, rustc today has "enabled" checking when debug_assertions is on, or when the user requests it via a flag. Otherwise, it leaves it to "default." If these checks ever become cheap enough, rustc may move to "enabled" in all cases by default. We'll see if that ever happens.

Sure but in practice Rust is as performant as C/C++ in benchmarks, so IMHO 'integer overflow is UB' should be scrapped..

The same argument applies to various other instances of undefined behaviour.

Integer division in Java never results in undefined behaviour. Divide-by-zero results in an exception, as does (Integer.MIN_VALUE / -1). In C/C++, both of those operations result in undefined behaviour. Modern JVMs have to generate some additional instructions to implement this [0], but I wonder if the real-world performance penalty is that substantial.

Another example is reading an uninitialized variable, which is undefined behaviour in C/C++. Does this footgun really improve performance, with modern compilers? I don't have a solid answer here but I suspect not.

> IMHO 'integer overflow is UB' should be scrapped

The C committee is opposed to radical change, they never want to step on the toes of exotic compilers and exotic hardware architectures, so I doubt they'll ever change it. I think it would be more realistic to ask the major compiler vendors to commit to never doing anything unsafe on signed integer overflow. I believe GCC has an 'opt-in' flag for this. I wonder what the performance cost is, if any. Perhaps it breaks some optimisations, but as you say, other fast languages like Rust seem to get by fine.

[0] https://www.javaer101.com/en/article/3166570.html

Am important thing to remember is that even with wrapping Rust maintains memory safety

Still, I agree, I prefer consistent semantics between dev/prod as much as possible. Especially since there's methods to have checked/wrapping/etc arithmetic, so I can always go to those if I want the other behavior

Thankfully, this behavior is a flag which you can personally configure to be consistent across dev/prod: https://doc.rust-lang.org/cargo/reference/profiles.html

It does make sense when interpreting wrapping checks in dev as debug assertions

> "we care about performance in release mode but we are also going to check and make sure this code does specific things on overflow".

More like:

> "integer overflow checks are a painful/unacceptable performance degradation for some use-cases, but we still want to cough over-/under-flow bugs during testing"

Anyway luckily you can just enable integer overflow checks in release builds, which is not a uncommon setup in use-cases like server code.

So, how do professional C programmers deal with this in general? Do they manually check for `x > MAX_INT || x < MIN_INT` every time they want to do some arithmetic? Do they manually check the CPU overflow flag after an operation? Or something else?

(I only have limited C experience, and only for hobby projects)

Either you need to restrict arithmetic to values which can’t overflow, or yes, you need to check for overflow manually. Note that you need to do those checks without actually triggering the overflow because once undefined behaviour is possible, all bets are off.

I see, so checking for the overflow flag wouldn't be good as you now have your program in an undefined state.

When I looked into doing this before I think the ultimate issue was that the C specification doesn't even give you any way to check the overflow flag.

So even if you knew your specific C implementation handled overflow properly there is no way to check the flag afterwards anyway.

This has nothing to do with C programming. If an arithmetic operation could overflow, you always have to add a check regardless of programming language. It's simply that a lot of high-level code doesn't care about such a level of correctness. Another exception are languages like Python that automatically upgrade your integers to arbitrary precision on overflow.

That said, most of the time you end up counting objects in the current address space. If you assume that there can exist no more than `SIZE_MAX` objects in memory, you can avoid many overflow checks.

My question does have to do with C programming. Other languages (not C++ of course) do not have signed overflow considered an undefined behaviour. My question is specifically about this.

The point is that integer overflow practically always indicates a programming error. How a certain languages handles integer overflows is secondary. These overflows shouldn't happen in the first place. Making overflows a well-defined operation actually hides programming errors.

With regard to C compilers, there are a few cases where a compiler performs optimizations because it assumes signed integer overflow cannot happen. This is bad but typically, compiled C behaves like the underlying platform which means signed integers wrap around. With GCC, you can enforce this behavior and make signed integer overflow a defined operation with `-fwrapv`. You can also compile your code with UBSan to get runtime checks during testing. UBSan can also check for unsigned integer overflow which is defined behavior in C. So with modern C compilers, the situation is basically the same as with Rust, Zig or other safer languages.

Well, first `x > MAX_INT || x < MIN_INT` makes little sense if x is an int, it will never be true. If adding a+b, you would check b > MAX_INT - a.

I would say that's very rare, only for special cases or defensive programming. Usually you either know/assert the operation will not overflow because the inputs are bounded, or you use wider types (e.g. use a int32_t when adding two int16_t).

C does not provide anything specific for this (though some have argued that it should). Many projects use compiler builtins such as __builtin_add_overflow.

Compile with -fwrapv.

Thanks, I just checked and also found out -ftrapv.

GCC says:

> This option generates traps for signed overflow on addition, subtraction, multiplication operations.

Use unsigned integers, which have well-defined overflow behavior.

In my experience with C (which is biased towards some specific use cases), most numbers that are likely to overflow are things like sizes and counts, which cannot meaningfully be negative anyway, so you may as well use unsigned integers for them. Other cases really do require signed integers, but for most arithmetic operations you can 'just' convert to unsigned before doing the arithmetic and then convert the result back to signed.

(Some may disagree. For instance, the Google C++ style guide [1] specifically says not to "use unsigned types to say a number will never be negative", because they want the undefined overflow behavior of signed types, in order to allow the compiler to diagnose bugs and to avoid "imped[ing] optimization". I think this is mostly nonsense; the drawbacks far outweigh the benefits, and tools for detecting overflow like UBSan can be told to check unsigned overflow as well.)

That said, even if you avoid the UB cases, checking for overflow correctly is hard; I've found many security vulnerabilities caused by missing or incorrect overflow checks. __builtin_add_overflow and friends are very nice if you have them, though unergonomic. I wish a more ergonomic version were standardized as part of the language.

[1] https://google.github.io/styleguide/cppguide.html

> (Some may disagree. For instance, the Google C++ style guide [1] specifically says not to "use unsigned types to say a number will never be negative", because they want the undefined overflow behavior of signed types, in order to allow the compiler to diagnose bugs and to avoid "imped[ing] optimization". I think this is mostly nonsense; the drawbacks far outweigh the benefits, and tools for detecting overflow like UBSan can be told to check unsigned overflow as well.)

Yes, I really disagree. unsigned integers mean one thing, which is "modular arithmetic". Unless you are in the very uncommon case of actually needing modular arithmetic, for instance, when implementing a crypto or hash algorithm, you want normal integers. As soon as you have anything that may have any chance of introducing a substraction somewhere, unsigned will cause bugs.

I don't know how many times I had to debug broken code such as

    for(int i = 0; i < some_size - 1; i++) { ... }

because some_size was unsigned.

If you really want a "number that cannot be negative", you don't wan't some_size - 1 to silently give you UINT_MAX, you want a type that will give you a compile-time or at worst run-time error.

Lets say some_size is the length or size of something. So that a negative number does not make sense, as there will only ever be a positive length or size (Is that actually the case for arrays and such?). Then how would you express that fact? What is your proposal for such a type?

the way to do it has been known for years: https://groups.google.com/a/isocpp.org/g/std-proposals/c/-KV...

Thank you for that. It is great, that this is known for years. I am not a regular C coder, so I am merely asking out of curiosity.

Could you supply a non-Google link to example code? Perhaps in some git repository or a code snippet on a non-Google snippet website?

Here's an example of a similar library: https://github.com/foonathan/type_safe

Aha, thank you, that's pretty cool! I wonder how they manage to make these types zero-overhead.

It can't be zero-overhead over e.g. int a,b ; a+b;

It's however zero-overhead wrt a+b plus the manual error checking you'd have to do if you wanted to be correct

It varies a lot depending on your needs. Here are a few options.

Parts of postgres just heavily document the allowed range and expected domain of such functions (effectively encoding a type system into the comments and relying on a human to enforce it).

I've seen people drop down into assembly to prevent UB. Note that checking the overflow flag doesn't necessarily suffice; the problem happens during compilation -- e.g. if you write `x = (x-MIN_INT)+MAX_INT;` the compiler might be able to reason that the only value for x which wouldn't have UB is MIN_INT. Consequently the result must be MAX_INT, and the compiler can inline that constant anywhere else it's used without ever issuing the instructions so that you could check an overflow flag if you wanted to. If you do those calculations in assembly then you have a lot more freedom in that regard.

Some projects do manually check every arithmetic call (or more commonly they'll lean on the pre-processor to do that kind of busywork for them), or at least they'll do so out of some small, core kernel which is more heavily vetted and can't afford the overhead.

Zig has a nullable pointer type, which will have null checks. But only in ReleaseSafe build mode, and it's trivial to construct a non nullable pointer that is null or uninitialised.

So I agree with your disagreement.

I'm not familiar with Zig, and I'm afraid I didn't quite follow your comment. Are you saying that "runtime" should instead be "none" for Zig?

Depends on the exact guarantees e.g. technically it's trivial to construct a nullable reference in Rust, but it's also `unsafe` and flagrantly UB so...

> it's trivial to construct a non nullable pointer that is null or uninitialised

This is checked at runtime in ReleaseSafe.

    jamie@machine:~$ cat test.zig
    pub fn main() void {
        var x: usize = 3;
        _ = @intToPtr(*u32, x - 3).*;
    }
    jamie@machine:~$ zig run test.zig -OReleaseSafe
    cast causes pointer to be null
    Aborted (core dumped)

(The x-3 is because if you use a literal 0 it gets caught at compile time)

> I don't think I understand what is meant by "type confusion". Surely this would also cause compile-time errors? Even C++ would give compile time errors for this unless you use a cast! (C, unlike C++, lets you implicitly convert from void* to any other pointer type so you don't need a cast to get pointer confusion.) Could someone think of an example of what might be meant here, and how it would cause a runtime error?

Given the foot-notes, I think they are referring to unions - probably writing to one union member but reading through another (e.g. uni.intVariant = 19; float a = uni.floatVariant).

I don't personally know how Rust and Zig handle this,I believe it is UB in C.

It's actually defined as doing a type pun on the bit representation, interestingly. (The history of this specific behavior is somewhat complicated–it wasn't always clear-cut what this did.)

[Edit: this isn't true] That is definitely how it is used, and it works on the major compilers. But, surprisingly, this is indeed undefined behaviour according to the standard. There was an infamous rant by Linus [1] (more infamous for the language than the subject) about how the kernel can and should continue to use unions for type punning. He noted that even though the C standard doesn't specify a behaviour for that usage, gcc does (so long as you don't use a particular compiler switch mentioned in that discussion), and went on to say "The standard simply is not important, when it is in direct conflict with reality and reliable code generation."

EDIT: Having looked into this more I think I was getting confused with C++ (where the only supported way to type pun is to use memcpy or similar, which despite the name might not have to actually copy the bytes at runtime). Here [2] is a StackOverflow answer (/discussion) on the matter.

[1] https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing/

[2] https://stackoverflow.com/questions/25664848/unions-and-type...

> The standard simply is not important

Does the Linux kernel still only support compilation using gcc? That’s about the only situation in which the standard could be considered “not important”. I wonder how many other C projects are in the same situation and only support the use of a single compiler?

Google builds Linux using Clang for Android and Chrome OS.

> Does the Linux kernel still only support compilation using gcc?

There was an effort to build the kernel with Clang [1], I'm not sure about its current status. It helps that Clang tracks GCC's features quite closely, including some of its idiosyncracies.

[1] https://lwn.net/Articles/734071/

No, the C standard defines it as I had specified:

> If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.

This verbiage has existed in a footnote of the standard since a defect report was filed against C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm. This happens to be one of the few instances where Linus is right about the C standard, but without knowing why ;)

Yep, you're right, my mistake

> I think they are referring to unions - probably writing to one union member but reading through another

Thanks, you could be right. In that case, I think it ought to be listed as a compile-time rather than a runtime error too (just as I already argued for null pointer dereference).

It depends a bit on use of course: if you have a function that takes an enum and considers all cases using pattern matching, then the compiler will stop you from accessing the wrong member within a given case. If you pass an enum to a function that expects one particular case to be active, then yes you can convert the compile time error into a run time one, but this is your own choice, not something that is naturally a run time error.

> but an attept to use the option without checking for None will result in an error at compile time, not runtime. Yes you could convert that into a runtime error, but if it was an error condition for that variable to be None then (depending on the context) you could choose not to use an Option at all and then it would be a compile-time error at the call site to attempt to put None into it.

This wording still suggests that it is a null pointer error reference, which is technically u.b., but in practice on any modern operating system a segmentation fault, but that is not what happens in Rust.

Rather, an optional reference cannot be dereferenced at all ere it be converted to an actual reference, typically with appropriate guards for the None-case, it is true that there is a way to convert an optional value of type `T` to type `T` without handling the None-case, but that is simply a trivial library function that handles the None-case by panicking the thread. The None-case must technically always be handled in some way in safe code.

The distinction is rather meaningful, I would say, as it is not the null pointer dereference stage where the error occurs, but the panicking of the thread of attempting to convert a None-case, which not only happens before that point, but provides for far cleaner debug information.

In safe Rust, one simply cannot dereference an optional reference, one can only coerce it to a reference, with the understanding that this operation panics the thread in the None-case. — an optional reference in Rust is not a “reference” at all as it is in other languages with special support for it.

I think it's fairly common in rust code to abuse unwrap and such behaving exactly like an unchecked access to a nullable type.

That's the opposite of true. Unwrap is heavily discouraged. I know for Result there is `?` operator, but I don't remember if that worked on Option.

Those are non mutually exclusive statements, it can be officially discouraged yet abused in practice because it often is for the developer the path of least resistance.

Heavily discouraged by who? I have seen many Rust projects and they were all filled with unwraps.

Two random Rust projects:

https://github.com/tokio-rs/tokio:

  $ grep -irn 'unwrap' | wc -l
  1398

https://github.com/denoland/deno:

  $ grep -irn 'unwrap' | wc -l
  2050

I dunno, but all Rust projects I have encountered had unwraps everywhere.

This really should get more attention. Safe null access in language like typescript or Kotlin through '?' syntax can still be abused through ('!!' ) but the incentive to abuse it is much lower than in rust because the safe syntax is just as short or shorter (in Kotlin)

This is the opposite of reality: in Rust, the safe syntax `?` exists and there is no short syntax for the panicking form (`.unwrap()`). Users are not incentivized to unwrap in Rust, users are as disincitivized as possible to unwrap.

The uses of unwrap in the projects the GP cited are overwhelmingly in tests and examples, which are not expected to handle errors in the same way as application code. The remainder are mainly lock poisoning unwrapping, which is a completely endorsed idiom.

For errors the ? operator is both correct and easy most of the time.

But for options it's trickier. Unless the surrounding function is structured just right, the equivalent to Typescript's and Kotlin's ? operator is .map()/.and_then(), and that's pretty ugly. .unwrap() is easier.

Try blocks might help.

I disagree with your characterization that "?" is the "safe syntax"; both are safe but one aborts execution.

Yeah, in tests and simple examples. But unwrap is a code smell. You can write it as a shorthand for something

Additionally that metric of yours is faulty.

A) Looks at tests/examples

B) Probably counts 'unwrap_or' which is fine.

> Heavily discouraged by who?

I'd ask to see however encouraged it?

You are right. I should not have even picked two random projects. I merely just wished to say that most Rust projects I have encountered contained a lot of unwrap.

Here's the score for tokio without tests and examples:

  $ find . -name '*.rs' | grep -v -e test -e example | xargs -n1 sed '/mod test/q' | grep -v '^\s*//' | grep -cF -e '.unwrap(' -e '.expect('
  224

I see a lot of unwrapping of locks. IIRC that only fails if another thread crashed while holding the lock, in which case crashing the current thread is often unobjectionable.

In addition to what Ygg2 mentioned (tests and unwrap_or), Rust is still (slowly) moving towards support of `Never` type that auto-erases impossible branches. Without `Never`, if you statically know that your function always returns `Option::Some`/`Result::Ok`, you have to use `.unwrap()` or `.expect("reason")`. This is just you doing the obvious work for the compiler that's not smart enough yet to figure it out by itself.

Unwrap is discouraged as an error handling scheme, it's fine when it means "I know this is Some". Every a[i] is an unwrap.

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

In rust an unwrap of a None is defined and memory safe.

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

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.

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

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.

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

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

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.

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.

There's a difference between a value being null, and a pointer being null. While Rust disallows both, it handles the cases differently; for the latter, a Rust program containing only safe Rust cannot create "null" references. However, for a "nullable" type, Rust encourages using `Option`, and forces you to handle the `null`/`None` case via a check.

Reply on news.ycombinator.com