31 ms·

I think the idea is that you tell the compiler to assume that this particular chunk of code does no wrong, and compiler shouldn't bother to try to prove it. Of

by setr 9y ago

I think the idea is that you tell the compiler to assume that this particular chunk of code does no wrong, and compiler shouldn't bother to try to prove it. Of course if you lie, then everything else can break down. But in general you're incentivized not to lie (and not to trust liars), so while its not provably "safe" to use, we can show everything else is safe as long as the assumption holds. The type system is sound, where it exists (in "safe" rust), and not sound where it doesn't (in "unsafe" rust). In the same fashion that nothing is sound if you don't trust your cpu to perform primitive operations correctly. But if you do trust it, then the type system has a chance at being "sound".

foldr 9y ago
>I think the idea is that you tell the compiler to assume that this particular chunk of code does no wrong, and compiler shouldn't bother to try to prove it. Of course if you lie, then everything else can break down. Right, but the same can be said for C++. If you can trust all of your not-provably-safe C++ code to be safe, then you can trust your whole codebase to be safe.
- Too 9y ago
  Ya, the difference is that in your 1MLOC code base you only have to review 10k lines with a microscope instead of every single one, the rest you can more or less trust to not do any funny business (with regards to memory).
  - foldr 9y ago
    Not true at all. All the 'unsafe' keyword does is allow a bunch of code constructs which are not allowed outside unsafe blocks. You can just as well limit your attention to that subset of constructs in your C++ code. You can't do it by grepping for 'unsafe', but you could do it using a C++ parser.
    - Too 9y ago
      Such a subset would be extremely limited and hardly be called c++ and i still don't think it would be possible, the problem is that these problems occur across files, not just because someone happened to use GOTO in isolation on line 123 in filexyz.cpp. Object ownership specifically is the biggest problem, you can enforce usage of shared/unique ptr everywhere but there are still instances where you might have passed a reference or raw pointer somewhere and then the last owning pointer goes out of scope in a callback function and the reference will point into whatever. Static allocation can solve a lot of this but then you are very constricted to the types of programs you can write. These are all the problems that the borrow checker avoids. I've used many static analysis tools and seen many things they can't catch, one example is if you forgot to check if your std::map::find returned end() before using the result? If you do so you are suddenly reading or writing into random memory.
      - foldr 9y ago
        Sure, but that has nothing to do with C++'s absence of an 'unsafe' keyword, or the presence of one in Rust. It has to do with differences in the actual language semantics (and in the unsafe design of the STL and common C++ coding practices).
        Too 9y ago
        It has everything to do with unsafe. Because outside unsafe you are forced to use the borrow checker, among other things, preventing you from thrashing memory with 100% guarantee. The number of ways you can thrash memory in c++ can't even by listed, especially not when it comes to object lifetime, so there is no equivalent subset of c++ providing those 100% guarantees. If you do such a mistake just once, the whole execution of the rest of your program might be randomized. Multiply all those possible mistakes with the size of your code base and you see the problem. In Rust, you have all these problems inside unsafe but the amount of code inside unsafe is much much smaller so it is feasible to only let your most senior guys write them and to review them extra thoroughly.
        9y ago

by setr 9y ago

foldr 9y ago

>I think the idea is that you tell the compiler to assume that this particular chunk of code does no wrong, and compiler shouldn't bother to try to prove it. Of course if you lie, then everything else can break down. Right, but the same can be said for C++. If you can trust all of your not-provably-safe C++ code to be safe, then you can trust your whole codebase to be safe.

Too 9y ago
Ya, the difference is that in your 1MLOC code base you only have to review 10k lines with a microscope instead of every single one, the rest you can more or less trust to not do any funny business (with regards to memory).
- foldr 9y ago
  Not true at all. All the 'unsafe' keyword does is allow a bunch of code constructs which are not allowed outside unsafe blocks. You can just as well limit your attention to that subset of constructs in your C++ code. You can't do it by grepping for 'unsafe', but you could do it using a C++ parser.
  - Too 9y ago
    Such a subset would be extremely limited and hardly be called c++ and i still don't think it would be possible, the problem is that these problems occur across files, not just because someone happened to use GOTO in isolation on line 123 in filexyz.cpp. Object ownership specifically is the biggest problem, you can enforce usage of shared/unique ptr everywhere but there are still instances where you might have passed a reference or raw pointer somewhere and then the last owning pointer goes out of scope in a callback function and the reference will point into whatever. Static allocation can solve a lot of this but then you are very constricted to the types of programs you can write. These are all the problems that the borrow checker avoids. I've used many static analysis tools and seen many things they can't catch, one example is if you forgot to check if your std::map::find returned end() before using the result? If you do so you are suddenly reading or writing into random memory.
    - foldr 9y ago
      Sure, but that has nothing to do with C++'s absence of an 'unsafe' keyword, or the presence of one in Rust. It has to do with differences in the actual language semantics (and in the unsafe design of the STL and common C++ coding practices).
      - Too 9y ago
        It has everything to do with unsafe. Because outside unsafe you are forced to use the borrow checker, among other things, preventing you from thrashing memory with 100% guarantee. The number of ways you can thrash memory in c++ can't even by listed, especially not when it comes to object lifetime, so there is no equivalent subset of c++ providing those 100% guarantees. If you do such a mistake just once, the whole execution of the rest of your program might be randomized. Multiply all those possible mistakes with the size of your code base and you see the problem. In Rust, you have all these problems inside unsafe but the amount of code inside unsafe is much much smaller so it is feasible to only let your most senior guys write them and to review them extra thoroughly.
        9y ago