4 ms·

It's true that one can't be sure the Rust version is "any more correct and won't eat all your memory". However, an even more important question is how many exp

by roca 10y ago

It's true that one can't be sure the Rust version is "any more correct and won't eat all your memory". However, an even more important question is how many exploitable bugs remain in the LLVM library vs the Rust library. The data suggests that the answer for Rust is zero but the answer for LLVM is greater than zero.

kbenson 10y ago
> The data suggests that the answer for Rust is zero Let's not go overboard. Claiming the number of bugs is zero in any non-trivial piece of software is generally a losing proposition, no matter the language. That said, I think I know what you're trying to express, and I would say it like this: The number of bugs in a program written in Rust compared to C or C++ should be statistically less, all other things being equal. Certain classes of bugs are impossible with Rust at best, and easier to locate or isolate at worst (assuming you haven't wrapped the entire program in one giant unsafe block).
- roca 10y ago
  For bugs in general sure, but I specifically said "exploitable bugs" which is a different story. I don't think it's going too far to say that the probability of a Rust compiler bug, or a bug in unsafe Rust library code, leading to an exploitable issue in the Rust demangler, is low.
  - kbenson 10y ago
    The implication being that it's impossible to write exploitable code without using unsafe? First, that's not a claim I've heard made, second, I'm far too conservative (having been around long enough) to believe Rust code in general can't be exploited, given enough time and effort by smart people, even if that's the current belief. Whole new classes of exploits occasionally pop up, and you can't reliably protect from that which you know nothing about.
pcwalton 10y ago
> The data suggests that the answer for Rust is zero but the answer for LLVM is greater than zero. Well, it's been fuzzed, so there's a pretty decent chance that the LLVM code has zero exploitable flaws. Also, the C++ demangler isn't as security-sensitive as many other more important projects. That said, as a general rule raw C-style string parsing, which that C++ code is an example of, is asking for trouble. It's painful to write, painful to maintain, painful to debug, and, when it fails, fails in the worst possible way. In my opinion there's little benefit to using C++ for these workloads.
- gens 10y ago
  >That said, as a general rule raw C-style string parsing, which that C++ code is an example of, is asking for trouble. It's painful to write, painful to maintain, painful to debug, and, when it fails, fails in the worst possible way. In my opinion there's little benefit to using C++ for these workloads. AFAIK Valgrind can catch many memory access related errors. And static analyzers can point out where such errors could happen. From a different perspective: Why don't people do pascal stile strings with C or C++ (and such) ? I think even i could make a library that does all the string.h things but with length-prefixed strings. People have been complaining for years now about C stile strings (that have been widely used for decades now). But nobody ever did anything about it ? PS I, myself, don't find it "painful" to use C stile strings. A few basic precautions (like using strncmp(bla,blaa,buffer_size)) and your fine. Off-by-one is more of a problem, at least for me at night (valgrind and llvm static analyzer point even those out).
  - pjmlp 10y ago
    > AFAIK Valgrind can catch many memory access related errors. And static analyzers can point out where such errors could happen. True, but Valgrind doesn't exist in every OS that one might need to work with, specially embedded ones, and according to Herb's talk at CppCon 2015, only 1% of the audience was using any form of static analyisis tooling. The world of C and C++ programming, in typical 9-5 enterprise jobs is quite different from HN ideals about code quality. > I think even i could make a library that does all the string.h things but with length-prefixed strings. People have been complaining for years now about C stile strings (that have been widely used for decades now). But nobody ever did anything about it ? Because it takes a big effort to make such library part of ANSI C. > PS I, myself, don't find it "painful" to use C stile strings. A few basic precautions (like using strncmp(bla,blaa,buffer_size)) and your fine. You already did a possible security exploit on your example, as you need to guarantee 100% of the time that bla and blaa sizes are always less or equal than buffer_size. When working with a team it suffices that another person changes your code without accounting for this invariant.

by roca 10y ago

kbenson 10y ago

> The data suggests that the answer for Rust is zero Let's not go overboard. Claiming the number of bugs is zero in any non-trivial piece of software is generally a losing proposition, no matter the language. That said, I think I know what you're trying to express, and I would say it like this: The number of bugs in a program written in Rust compared to C or C++ should be statistically less, all other things being equal. Certain classes of bugs are impossible with Rust at best, and easier to locate or isolate at worst (assuming you haven't wrapped the entire program in one giant unsafe block).

roca 10y ago
For bugs in general sure, but I specifically said "exploitable bugs" which is a different story. I don't think it's going too far to say that the probability of a Rust compiler bug, or a bug in unsafe Rust library code, leading to an exploitable issue in the Rust demangler, is low.
- kbenson 10y ago
  The implication being that it's impossible to write exploitable code without using unsafe? First, that's not a claim I've heard made, second, I'm far too conservative (having been around long enough) to believe Rust code in general can't be exploited, given enough time and effort by smart people, even if that's the current belief. Whole new classes of exploits occasionally pop up, and you can't reliably protect from that which you know nothing about.

pcwalton 10y ago

> The data suggests that the answer for Rust is zero but the answer for LLVM is greater than zero. Well, it's been fuzzed, so there's a pretty decent chance that the LLVM code has zero exploitable flaws. Also, the C++ demangler isn't as security-sensitive as many other more important projects. That said, as a general rule raw C-style string parsing, which that C++ code is an example of, is asking for trouble. It's painful to write, painful to maintain, painful to debug, and, when it fails, fails in the worst possible way. In my opinion there's little benefit to using C++ for these workloads.

gens 10y ago
>That said, as a general rule raw C-style string parsing, which that C++ code is an example of, is asking for trouble. It's painful to write, painful to maintain, painful to debug, and, when it fails, fails in the worst possible way. In my opinion there's little benefit to using C++ for these workloads. AFAIK Valgrind can catch many memory access related errors. And static analyzers can point out where such errors could happen. From a different perspective: Why don't people do pascal stile strings with C or C++ (and such) ? I think even i could make a library that does all the string.h things but with length-prefixed strings. People have been complaining for years now about C stile strings (that have been widely used for decades now). But nobody ever did anything about it ? PS I, myself, don't find it "painful" to use C stile strings. A few basic precautions (like using strncmp(bla,blaa,buffer_size)) and your fine. Off-by-one is more of a problem, at least for me at night (valgrind and llvm static analyzer point even those out).
- pjmlp 10y ago
  > AFAIK Valgrind can catch many memory access related errors. And static analyzers can point out where such errors could happen. True, but Valgrind doesn't exist in every OS that one might need to work with, specially embedded ones, and according to Herb's talk at CppCon 2015, only 1% of the audience was using any form of static analyisis tooling. The world of C and C++ programming, in typical 9-5 enterprise jobs is quite different from HN ideals about code quality. > I think even i could make a library that does all the string.h things but with length-prefixed strings. People have been complaining for years now about C stile strings (that have been widely used for decades now). But nobody ever did anything about it ? Because it takes a big effort to make such library part of ANSI C. > PS I, myself, don't find it "painful" to use C stile strings. A few basic precautions (like using strncmp(bla,blaa,buffer_size)) and your fine. You already did a possible security exploit on your example, as you need to guarantee 100% of the time that bla and blaa sizes are always less or equal than buffer_size. When working with a team it suffices that another person changes your code without accounting for this invariant.