4 ms·

Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. C

by ekidd 10y ago

Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at compile time—but not all. 2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak. 3. Expected run-time errors. These are mostly reported using return values of type Error, which is the normal way to handle errors in Rust. Most of the errors caught by AFL seem to be errors in group (2) that ought to be in group (3). In most cases, these errors couldn't be moved into group (1), because they're not the kind of thing that's easily caught at compile-time. So this is a really cool tool for Rust developers, especially ones working on libraries that parse untrusted input. I was especially impressed by the fact that AFL could discover overflow errors, which Rust normally only protects against in Debug mode.

eddyb 10y ago
> These are mostly reported using return values of type Error However, unlike more dynamic languages, the return types are usually Result<SuccessValue, SomeErrorType>, e.g. writing to a file or a socket will get you Result<usize, io::Error>, values of which can be Ok(usize) (the number of bytes written) or Err(io::Error) (an I/O error which you can further inspect). Although if you want to, you can use Result<T, Box<Error>> where Error is a trait implemented by types representing some error information. You then lose the ability to inspect errors other than for reporting them wholesale, but the APIs are slightly more uniform, type-wise. You can read about all of this and more in the dedicated chapter of the official Rust Book: https://doc.rust-lang.org/book/error-handling.html https://doc.rust-lang.org/book/error-handling.html.
- ekidd 10y ago
  > However, unlike more dynamic languages, the return types are usually Result<SuccessValue, SomeErrorType> Yes, this is a more complete and precise explanation. :-) I rather like Rust's error handling in practice—it adds only a small amount of syntactic noise, and even the annoying bits (such as converting and wrapping error types) can mostly be isolated in a single file per project.
pslam 10y ago
> 2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak. I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. I strongly disagree with the idea that it's a Debug feature only. If it's not always on, then it's not actually a language feature. The performance hit, if you selectively opt-out for profiled critical paths (and thoroughly review them), is usually very small. In my opinion the default should switch to "opt-out" instead of "opt-in" for Release builds.
- ekidd 10y ago
  > I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. Yeah, I remember when the debug-mode overflow checks were added right before Rust 1.0. There wasn't enough time remaining to thoroughly measure the performance impact of these checks in release mode or to implement compiler optimizations to reduce the cost. So IIRC, the decision was made to allow integer overflows to panic, and to turn on checks in debug mode so that the ecosystem wouldn't come to depend on the absence of checks. But AFAICT, the debug-mode checks are basically still a placeholder for some indefinite future version of Rust that wants to fix this issue properly, if the performance cost can be made low enough. And in the meantime, you can still turn the checks on for release builds if the performance hit is acceptable for your application. I'll consider your recommendation when building binaries in the future!
  - pslam 10y ago
    > if the performance cost can be made low enough I think that's the wrong way to look at it. How about instead: "Checks can be disabled if the safety cost is worth the performance increase" The "performance case" is a false baseline. You never had that performance in the first place, because your code didn't work.
    - kbenson 10y ago
      It's a fine line to walk. Performance is a deal breaker for a lot of people, whether it rightly should be of not. It doesn't matter how much safer Rust is if it's not used much. If your goal is purely to make Rust as safe as possible, then you should advocate the view in your comment. If your goal is to increase Rust adoption, and/or decrease the use of less safe languages for development in the future (in whichever prioritization of the two you like), then IMO the route described in ekidd's comment seems the quickest route there, IMO.
briansmith 10y ago
If you're parsing untrusted input, you should try to systemically avoid panics. Easier said than done, but I have started a small framework for protocol parsers called untrusted.rs that helps: https://github.com/briansmith/untrusted https://github.com/briansmith/untrusted. The main idea is that most panics (in parsers) are going to be caused by using the indexing operator on slices containing the untrusted input, so we wrap the input in a type that hides the slicing functionality, giving us only methods that return 'Result's. nom is a much fancier thing which, IIUC, solves the same problems, and more: https://github.com/Geal/nom https://github.com/Geal/nom.

by ekidd 10y ago

eddyb 10y ago

> These are mostly reported using return values of type Error However, unlike more dynamic languages, the return types are usually Result<SuccessValue, SomeErrorType>, e.g. writing to a file or a socket will get you Result<usize, io::Error>, values of which can be Ok(usize) (the number of bytes written) or Err(io::Error) (an I/O error which you can further inspect). Although if you want to, you can use Result<T, Box<Error>> where Error is a trait implemented by types representing some error information. You then lose the ability to inspect errors other than for reporting them wholesale, but the APIs are slightly more uniform, type-wise. You can read about all of this and more in the dedicated chapter of the official Rust Book: https://doc.rust-lang.org/book/error-handling.html https://doc.rust-lang.org/book/error-handling.html.

ekidd 10y ago
> However, unlike more dynamic languages, the return types are usually Result<SuccessValue, SomeErrorType> Yes, this is a more complete and precise explanation. :-) I rather like Rust's error handling in practice—it adds only a small amount of syntactic noise, and even the annoying bits (such as converting and wrapping error types) can mostly be isolated in a single file per project.

pslam 10y ago

> 2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak. I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. I strongly disagree with the idea that it's a Debug feature only. If it's not always on, then it's not actually a language feature. The performance hit, if you selectively opt-out for profiled critical paths (and thoroughly review them), is usually very small. In my opinion the default should switch to "opt-out" instead of "opt-in" for Release builds.

ekidd 10y ago
> I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. Yeah, I remember when the debug-mode overflow checks were added right before Rust 1.0. There wasn't enough time remaining to thoroughly measure the performance impact of these checks in release mode or to implement compiler optimizations to reduce the cost. So IIRC, the decision was made to allow integer overflows to panic, and to turn on checks in debug mode so that the ecosystem wouldn't come to depend on the absence of checks. But AFAICT, the debug-mode checks are basically still a placeholder for some indefinite future version of Rust that wants to fix this issue properly, if the performance cost can be made low enough. And in the meantime, you can still turn the checks on for release builds if the performance hit is acceptable for your application. I'll consider your recommendation when building binaries in the future!
- pslam 10y ago
  > if the performance cost can be made low enough I think that's the wrong way to look at it. How about instead: "Checks can be disabled if the safety cost is worth the performance increase" The "performance case" is a false baseline. You never had that performance in the first place, because your code didn't work.
  - kbenson 10y ago
    It's a fine line to walk. Performance is a deal breaker for a lot of people, whether it rightly should be of not. It doesn't matter how much safer Rust is if it's not used much. If your goal is purely to make Rust as safe as possible, then you should advocate the view in your comment. If your goal is to increase Rust adoption, and/or decrease the use of less safe languages for development in the future (in whichever prioritization of the two you like), then IMO the route described in ekidd's comment seems the quickest route there, IMO.

briansmith 10y ago

If you're parsing untrusted input, you should try to systemically avoid panics. Easier said than done, but I have started a small framework for protocol parsers called untrusted.rs that helps: https://github.com/briansmith/untrusted https://github.com/briansmith/untrusted. The main idea is that most panics (in parsers) are going to be caused by using the indexing operator on slices containing the untrusted input, so we wrap the input in a type that hides the slicing functionality, giving us only methods that return 'Result's. nom is a much fancier thing which, IIUC, solves the same problems, and more: https://github.com/Geal/nom https://github.com/Geal/nom.