5 ms·

To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map t

To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map to handle None cases gracefully), so this is a class of test that would be common in Java and C that is close to irrelevant in Rust.

tialaramex 3y ago
To be more specific, Rust does have among other things: std::ptr::null() - an actual null pointer, probably the zero address on your hardware, and this isn't even an unsafe function. On the other hand, you won't find many uses for a null pointer so, I mean, congrats on obtaining one and good luck with that. std::ptr::null_mut() - a mutable null pointer, similarly unlikely to be of any use to you in safe Rust, but also not an unsafe thing to ask for. But, these are pointers, so they're not values that say, a String could take, or a Vec<String> or whatever, only actual raw pointers can be null.
- pornel 3y ago
  And even for raw pointers you can use NonNull<T>.
- deleted 3y ago
  [deleted]
benibela 3y ago
Still someone might call unwrap on an Option and then run into some kind of null pointer exception
- maxbond 3y ago
  Sure, you can panic unwrapping a None, but there are two important distinctions. First, this is a controlled panic, not a segmentation fault. The language is ensuring that we don't access the null pointer, or an offset from the null pointer. Null pointer access can be exploitable in certain circumstances (eg, a firmware or kernel). Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.
  - benibela 3y ago
    >First, this is a controlled panic, not a segmentation fault. But a segmentation fault is also controlled >Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. No, I am thinking in Delphi terms. It is overspecialized to Windows userspace. Windows gives an Access Violation, and that can be caught, and Delphi throws it as exception >Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type. Delphi has both nullable types and null-safe types
    - maxbond 3y ago
      > But a segmentation fault is also controlled A segmentation fault may not happen (which is to say, we may corrupt memory or worse) if the null pointer is mapped into memory (as in an embedded or kernel context) or if it's accessed at a large offset, which results in a pointer that's mapped into memory. This may be rotten luck or it may be exploited by an attacker. > No, I am thinking in Delphi terms. Fair enough, I don't know Delphi. I'll take what you're saying about it as read.

tialaramex 3y ago

To be more specific, Rust does have among other things: std::ptr::null() - an actual null pointer, probably the zero address on your hardware, and this isn't even an unsafe function. On the other hand, you won't find many uses for a null pointer so, I mean, congrats on obtaining one and good luck with that. std::ptr::null_mut() - a mutable null pointer, similarly unlikely to be of any use to you in safe Rust, but also not an unsafe thing to ask for. But, these are pointers, so they're not values that say, a String could take, or a Vec<String> or whatever, only actual raw pointers can be null.

pornel 3y ago
And even for raw pointers you can use NonNull<T>.
deleted 3y ago
[deleted]

benibela 3y ago

Still someone might call unwrap on an Option and then run into some kind of null pointer exception

maxbond 3y ago
Sure, you can panic unwrapping a None, but there are two important distinctions. First, this is a controlled panic, not a segmentation fault. The language is ensuring that we don't access the null pointer, or an offset from the null pointer. Null pointer access can be exploitable in certain circumstances (eg, a firmware or kernel). Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.
- benibela 3y ago
  >First, this is a controlled panic, not a segmentation fault. But a segmentation fault is also controlled >Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. No, I am thinking in Delphi terms. It is overspecialized to Windows userspace. Windows gives an Access Violation, and that can be caught, and Delphi throws it as exception >Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type. Delphi has both nullable types and null-safe types
  - maxbond 3y ago
    > But a segmentation fault is also controlled A segmentation fault may not happen (which is to say, we may corrupt memory or worse) if the null pointer is mapped into memory (as in an embedded or kernel context) or if it's accessed at a large offset, which results in a pointer that's mapped into memory. This may be rotten luck or it may be exploited by an attacker. > No, I am thinking in Delphi terms. Fair enough, I don't know Delphi. I'll take what you're saying about it as read.