5 ms·

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

Ygg2 9y ago
Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).
- megous 9y ago
  Check it when you use it?
  - sgift 9y ago
    Experience tells us that this idea doesn't work so well in practice without a compiler yelling if you don't do it.
    - megous 9y ago
      Compiler doesn't yell, because it's unnecessary in most cases. My experience is that huge amount of C code running on my computer had exactly zero issues like this today. It has been working perfectly fine. I run GNOME which uses a paradigm of checking all inputs to a function on entry via g_return(_val)_if_fail(assertion_expression). It helps the programmer do the right thing when it comes to using APIs that are disallowing NULL input. Two days ago, the code on my workstation hit one of those "assertions": Sep 26 23:40:31 core transmission-gt[1084]: g_file_test: assertion 'filename != NULL' failed No oops in the kernel recently. Millions of lines of desktop and kernel code, and one failed assertion in two days for using NULL incorrectly in the API. So unless your standard is absolute perfection, it works fine as is.
- Jyaif 9y ago
  thankfully C++ has references.
  - imron 9y ago
    References can still be null.
    - ekidd 9y ago
      In C++, null references are Very Bad, and they trigger undefined behavior: https://stackoverflow.com/questions/4364536/is-null-reference-possible https://stackoverflow.com/questions/4364536/is-null-referenc... I don't think I've ever run into a null reference in the real world. I'm sure it happens, especially if people write "&*some_function_that_might_return_null()". But it shouldn't be a normal thing. There are lots of other issues with C++, but this has never been a major one in my experience.
      - imron 9y ago
        > In C++, null references are Very Bad, They are! And while they are not a normal thing, they are a thing and I've run in to them a handful of times in the real world, almost always the result of someone not checking for null before dereferencing a pointer. Rust does not really have this issue.
        pjmlp 9y ago
        Rust also has this issue, unless you fully validate every single pointer coming out of unsafe blocks.
        imron 9y ago
        The difference being that all c++ code is 'unsafe' in the rust sense, whereas a typical rust program will have only a small portion of unsafe code (or none), making it easier to fully validate - hence 'doesn't really have this problem'.
- bjz_ 9y ago
  Null is not really the most pertinent example in this context - at least you get a segfault. What is more important is that in C or C++ (even C++17), it is trivially easy to produce buffer overruns, use after frees, dangling pointers, invalidated iterators, data races etc. That is the unsafety that we are talking about here. Opt-in nullability via Option<T> is nice to have though.
  - Ygg2 9y ago
    Yeah, I went with familiarity/simplicity in that example. My point was similar C/C++ don't have a safe subset.
    - adrianN 9y ago
      Not a safe subset anyone would want to use at least. You could just not use pointers in your code and you'd have memory safety.
      - steveklabnik 9y ago
        Your code, or any of the code it calls; iterator invalidation, for example, wouldn't force you to use pointers directly, but can still cause memory unsafety.
  - steveklabnik 9y ago
    > at least you get a segfault If the platform has an MMU, if you've properly set up your page table mappings, etc. We are talking about writing an OS here! Not to mention all the UB around null pointers that can cause miscompilation. Well, not technically miscompilation, but stuff like https://news.ycombinator.com/item?id=15324414 https://news.ycombinator.com/item?id=15324414
  - ctz 9y ago
    > at least you get a segfault. If there were a list "falsehoods software engineers believe about memory safety" this should be there. https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf
bjz_ 9y ago
In C and C++ you have to treat everything as unsafe, because you have neither a GC nor a compiler to help tell you when you have accidentally violated some memory management invariant that some API was depending on. Rust's type system gives you the tools to define those safe APIs and have them checked by the compiler, even if you need to do some unsafe shenanigans under the hood.

>But in most cases, you can encapsulate the low-level hardware inside a safe API I'm probably missing something obvious. But isn't that true for most languages?

Ygg2 9y ago

Not really. I mean let's say you program in C, how will you enforce some pointer is never null? In Rust you can say &Object and that reference is never null (modulo any unsafe shenanigans).

megous 9y ago
Check it when you use it?
- sgift 9y ago
  Experience tells us that this idea doesn't work so well in practice without a compiler yelling if you don't do it.
  - megous 9y ago
    Compiler doesn't yell, because it's unnecessary in most cases. My experience is that huge amount of C code running on my computer had exactly zero issues like this today. It has been working perfectly fine. I run GNOME which uses a paradigm of checking all inputs to a function on entry via g_return(_val)_if_fail(assertion_expression). It helps the programmer do the right thing when it comes to using APIs that are disallowing NULL input. Two days ago, the code on my workstation hit one of those "assertions": Sep 26 23:40:31 core transmission-gt[1084]: g_file_test: assertion 'filename != NULL' failed No oops in the kernel recently. Millions of lines of desktop and kernel code, and one failed assertion in two days for using NULL incorrectly in the API. So unless your standard is absolute perfection, it works fine as is.
Jyaif 9y ago
thankfully C++ has references.
- imron 9y ago
  References can still be null.
  - ekidd 9y ago
    In C++, null references are Very Bad, and they trigger undefined behavior: https://stackoverflow.com/questions/4364536/is-null-reference-possible https://stackoverflow.com/questions/4364536/is-null-referenc... I don't think I've ever run into a null reference in the real world. I'm sure it happens, especially if people write "&*some_function_that_might_return_null()". But it shouldn't be a normal thing. There are lots of other issues with C++, but this has never been a major one in my experience.
    - imron 9y ago
      > In C++, null references are Very Bad, They are! And while they are not a normal thing, they are a thing and I've run in to them a handful of times in the real world, almost always the result of someone not checking for null before dereferencing a pointer. Rust does not really have this issue.
      - pjmlp 9y ago
        Rust also has this issue, unless you fully validate every single pointer coming out of unsafe blocks.
        imron 9y ago
        The difference being that all c++ code is 'unsafe' in the rust sense, whereas a typical rust program will have only a small portion of unsafe code (or none), making it easier to fully validate - hence 'doesn't really have this problem'.
bjz_ 9y ago
Null is not really the most pertinent example in this context - at least you get a segfault. What is more important is that in C or C++ (even C++17), it is trivially easy to produce buffer overruns, use after frees, dangling pointers, invalidated iterators, data races etc. That is the unsafety that we are talking about here. Opt-in nullability via Option<T> is nice to have though.
- Ygg2 9y ago
  Yeah, I went with familiarity/simplicity in that example. My point was similar C/C++ don't have a safe subset.
  - adrianN 9y ago
    Not a safe subset anyone would want to use at least. You could just not use pointers in your code and you'd have memory safety.
    - steveklabnik 9y ago
      Your code, or any of the code it calls; iterator invalidation, for example, wouldn't force you to use pointers directly, but can still cause memory unsafety.
- steveklabnik 9y ago
  > at least you get a segfault If the platform has an MMU, if you've properly set up your page table mappings, etc. We are talking about writing an OS here! Not to mention all the UB around null pointers that can cause miscompilation. Well, not technically miscompilation, but stuff like https://news.ycombinator.com/item?id=15324414 https://news.ycombinator.com/item?id=15324414
- ctz 9y ago
  > at least you get a segfault. If there were a list "falsehoods software engineers believe about memory safety" this should be there. https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf

bjz_ 9y ago

In C and C++ you have to treat everything as unsafe, because you have neither a GC nor a compiler to help tell you when you have accidentally violated some memory management invariant that some API was depending on. Rust's type system gives you the tools to define those safe APIs and have them checked by the compiler, even if you need to do some unsafe shenanigans under the hood.