5 ms·

The "goto fail" bug isn't a great example; Rust actually does specifically guard against this by requiring curly braces around the body of "if". Here's an expl

The "goto fail" bug isn't a great example; Rust actually does specifically guard against this by requiring curly braces around the body of "if". Here's an explanation of "goto fail", which includes a code snippet. https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got... If C conditionals required explicit braces around the body, the second fail would have been redundant code instead of a security vulnerability. Additonally, Rust will warn you if you have "unreachable" code, such as all the code after the unconditional "goto fail". Though, I'm sure modern C compilers would also warn about this. All that said, Rust definitely does have plenty of bug classes left for people to trip over. Integer under/overflows come to mind (though they're just logic errors instead of undefined behavior).

tialaramex 5y ago
In the same class as the integer over/underflows, Rust also doesn't warn for throwing away information when casting. So (my_value as u16) might be a completely safe transformation from an unsigned one byte my_value to a u16, but it might be throwing away the top 16-bits of a 32-bit value and Rust doesn't think that's worth any additional caution. Rust also hasn't boarded the "People can't remember precedence rules" train like some modern languages. It has fewer operators with unnecessary values, reducing some opportunities for mistakes like C's increment footgun, but it does still have precedence and so you can still forget the precedence rules which the compiler is going to apply to your code. But there are a lot of things Rust does catch, and there are even more things that aren't caught by Rust the language per se but are caught in idiomatic Rust because the language affords better ways to do things. Locking is an example, idiomatic Rust locking means you can't make the lock A but change B mistake seen so often in real bugs, because idiomatic use of Rust's type system would put the variable B inside the lock for B, if you didn't take the lock you don't have the variable to change it. https://doc.rust-lang.org/std/sync/struct.Mutex.html https://doc.rust-lang.org/std/sync/struct.Mutex.html
- pjmlp 5y ago
  Another example would be bounds checking, yes it is much better than silenty corrupting memory, but dying with a panic might not be the best solution in some cases, specially if the application is controlling hardware. Not only Rust, this applies to all safe languages, just crashing also opens the door to exploits and denial attacks.
  - tialaramex 5y ago
    If the bounds check fails at compile time then the program doesn't compile. This seems like it should be a reasonable ask for any programming language, but, apparently not. And it probably applies to all general purpose languages but of course it doesn't apply to all the safe languages that aren't general purpose. You can't have bounds misses in WUFFS. When you try to touch array[x] in WUFFS, the compiler constrains the type of x to have a boundary limit according to the size of the array, reasoning that you can't very well have meant for it to be possible to overstep the bounds of the array at runtime. Trivial arithmetic mistakes you might find in unit testing or worse production with other languages are often compile time errors in WUFFS as a result.
    - pjmlp 5y ago
      Except bounds checking fail at runtime like 90% of the time.
      - tialaramex 5y ago
        Well, like I said, in WUFFS this literally can't happen, WUFFS doesn't have any concept of runtime bounds checking, likewise it has no runtime overflow/underflow checking, if the compiler can't see why what you're doing will obey the constraints you don't have a valid WUFFS program at all (well, library, WUFFS is a special-purpose language so you're not going to go around writing whole programs in WUFFS) And it's still a pretty sad indictment when a compiler is looking at your access, can see it's outside the boundaries and doesn't reject the program because the language (e.g. C) wasn't defined with this obvious expectation. For me it's in the same category as the (now fixed in an errata) behaviour where as I understand it C++ 20 std::format didn't consider it a compile time error if you wrote format("check X: {} Y: {} and Z: {}", x, z) ... even though that's obviously an error, and it's obvious you can detect it at compile time, the original specification said nah, this code just blows up at runtime, good luck with that.

tialaramex 5y ago

In the same class as the integer over/underflows, Rust also doesn't warn for throwing away information when casting. So (my_value as u16) might be a completely safe transformation from an unsigned one byte my_value to a u16, but it might be throwing away the top 16-bits of a 32-bit value and Rust doesn't think that's worth any additional caution. Rust also hasn't boarded the "People can't remember precedence rules" train like some modern languages. It has fewer operators with unnecessary values, reducing some opportunities for mistakes like C's increment footgun, but it does still have precedence and so you can still forget the precedence rules which the compiler is going to apply to your code. But there are a lot of things Rust does catch, and there are even more things that aren't caught by Rust the language per se but are caught in idiomatic Rust because the language affords better ways to do things. Locking is an example, idiomatic Rust locking means you can't make the lock A but change B mistake seen so often in real bugs, because idiomatic use of Rust's type system would put the variable B inside the lock for B, if you didn't take the lock you don't have the variable to change it. https://doc.rust-lang.org/std/sync/struct.Mutex.html https://doc.rust-lang.org/std/sync/struct.Mutex.html

pjmlp 5y ago
Another example would be bounds checking, yes it is much better than silenty corrupting memory, but dying with a panic might not be the best solution in some cases, specially if the application is controlling hardware. Not only Rust, this applies to all safe languages, just crashing also opens the door to exploits and denial attacks.
- tialaramex 5y ago
  If the bounds check fails at compile time then the program doesn't compile. This seems like it should be a reasonable ask for any programming language, but, apparently not. And it probably applies to all general purpose languages but of course it doesn't apply to all the safe languages that aren't general purpose. You can't have bounds misses in WUFFS. When you try to touch array[x] in WUFFS, the compiler constrains the type of x to have a boundary limit according to the size of the array, reasoning that you can't very well have meant for it to be possible to overstep the bounds of the array at runtime. Trivial arithmetic mistakes you might find in unit testing or worse production with other languages are often compile time errors in WUFFS as a result.
  - pjmlp 5y ago
    Except bounds checking fail at runtime like 90% of the time.
    - tialaramex 5y ago
      Well, like I said, in WUFFS this literally can't happen, WUFFS doesn't have any concept of runtime bounds checking, likewise it has no runtime overflow/underflow checking, if the compiler can't see why what you're doing will obey the constraints you don't have a valid WUFFS program at all (well, library, WUFFS is a special-purpose language so you're not going to go around writing whole programs in WUFFS) And it's still a pretty sad indictment when a compiler is looking at your access, can see it's outside the boundaries and doesn't reject the program because the language (e.g. C) wasn't defined with this obvious expectation. For me it's in the same category as the (now fixed in an errata) behaviour where as I understand it C++ 20 std::format didn't consider it a compile time error if you wrote format("check X: {} Y: {} and Z: {}", x, z) ... even though that's obviously an error, and it's obvious you can detect it at compile time, the original specification said nah, this code just blows up at runtime, good luck with that.