Unwrap can definitely bring down a Rust program but it's definitely not nearly as bad as null pointers in C, C++, Java, etc.
1. You have to explicitly add `unwrap()`, in C you just have to forget to add a null check which is a lot easier to do. The compiler won't remind you like it does in Rust. The bug is opt-out-if-you-remember not opt-in-if-you're-lazy.
2. The crash is safe. Usually a null pointer crash is safe but I've definitely seen cases where it leads to impossible-to-debug random failures.
3. You can see `unwrap()`s in code review easily.
4. You can actually catch panics, which is probably a good idea in high availability systems like a web server. I don't know if people actually do this in practice though.
Usually it's possible to write similar bugs in Rust but it's also far less likely that you would (though it does definitely happen). So Rust does at least help with this even if it doesn't fully prevent the issue.
but a call to unwrap is usually more explicit than a null pointer dereference when you are reviewing code. if you are deserializing something from an external source and calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells. of course maybe everyone agrees the external source should not be sending such data and it goes into prod anyway. but also its possible everyone agrees its worth putting some extra effort into not crashing the process in such a situation because there is too much risk.
>calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells
Yeah, definitely. And the equivalent without optional types, dereferencing a null pointer, might happen because they don't even realize it could be null in the first place. Not everyone writes "assert(ptr != 0)" every time they assume a pointer isn't null, because it happens frequently (if the code doesn't use references enough, which IIRC happens with Google).
When you have an option type, you're made aware of it explicitly, and calling `.unwrap()` should, like you said, raise alarm bells and make you think anout whether you actually want to crash the program.
In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes. You can unwind and catch panics in Rust, but I’m not sure if that would have helped in this scenario as it might have immediately went directly into the fault code again.
However, I would assume that the presence of an «unwrap» would have been caught in code review, whereas it’s much harder to be aware of which pointers can be null in Java/C++.
Pretty sure it's C++.
inb4 someone yells Rust. No, your `.unwrap()` happily panics in Rust too.
Unwrap can definitely bring down a Rust program but it's definitely not nearly as bad as null pointers in C, C++, Java, etc.
1. You have to explicitly add `unwrap()`, in C you just have to forget to add a null check which is a lot easier to do. The compiler won't remind you like it does in Rust. The bug is opt-out-if-you-remember not opt-in-if-you're-lazy.
2. The crash is safe. Usually a null pointer crash is safe but I've definitely seen cases where it leads to impossible-to-debug random failures.
3. You can see `unwrap()`s in code review easily.
4. You can actually catch panics, which is probably a good idea in high availability systems like a web server. I don't know if people actually do this in practice though.
Usually it's possible to write similar bugs in Rust but it's also far less likely that you would (though it does definitely happen). So Rust does at least help with this even if it doesn't fully prevent the issue.
but a call to unwrap is usually more explicit than a null pointer dereference when you are reviewing code. if you are deserializing something from an external source and calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells. of course maybe everyone agrees the external source should not be sending such data and it goes into prod anyway. but also its possible everyone agrees its worth putting some extra effort into not crashing the process in such a situation because there is too much risk.
>calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells
Yeah, definitely. And the equivalent without optional types, dereferencing a null pointer, might happen because they don't even realize it could be null in the first place. Not everyone writes "assert(ptr != 0)" every time they assume a pointer isn't null, because it happens frequently (if the code doesn't use references enough, which IIRC happens with Google).
When you have an option type, you're made aware of it explicitly, and calling `.unwrap()` should, like you said, raise alarm bells and make you think anout whether you actually want to crash the program.
How is panicking the same as dereferencing a null pointer, which is undefined behavior?
In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes. You can unwind and catch panics in Rust, but I’m not sure if that would have helped in this scenario as it might have immediately went directly into the fault code again.
However, I would assume that the presence of an «unwrap» would have been caught in code review, whereas it’s much harder to be aware of which pointers can be null in Java/C++.
2 replies →
you don't even need turing-completeness to write a bug that takes down prod :-)