Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
Do you have more of these examples?
Regex: badly needs fuzzing
41–50 of 180 posts
Re: Regex: badly needs fuzzing
#42Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
Well, yes if the strawman "all modern C++ written by experts is free from memory safety issues" is what you're countering. I find that to be gratuitous and petty, and not a good representation of Rust, however.
The position "modern C++ is safe and all C programmers are idiots" is repeated quite often here on HN.
To be fair, it is always the same small group of people who do that.
Re: Regex: badly needs fuzzing
#43Earlier quoted context omitted.
If the solution doesnt make it any easier to avoid memory issues (just forces you to avoid them,) its not an attractive solution
Avoiding bugs is a pretty effective way to not have bugs.
Avoiding bugs is the default in software development in any language, no? If you have pointer DSL that can lead to various bugs, replacing it with a more complex pointer DSL is not a good way to avoid bugs. And I don't think C++ 'smart pointers' and other crap are very simple (relative to C pointers) or much less error-prone. That's just my opinion though.
Re: Regex: badly needs fuzzing
#44Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
If it has memory safety issues then it's not written by experts :)
Re: Regex: badly needs fuzzing
#45Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
Ignoring the straw man, can you explain how c++98 code provides a counterexample for anything in modern c++?
Re: Regex: badly needs fuzzing
#46Earlier quoted context omitted.
I've seen plenty of places that you may want to accept an arbitrary regex from the user. An app could allow the user to set up a filter for messages or usernames by putting in a regex. Or an interpreter for a sandboxed language could provide regex support.
All manner of problems in the programmers mind become trivial if only we allow users to input essentially code to express exactly what they want. Of course this is basically never a good solution. The issue with allowing arbitrary regex patterns is DoS through exponential blowup. But if you allow running code anyway you might not very much care for that.
DoS's can be limited by isolating the regular expression from the rest of the program and limiting its resource utilisation.
Re: Regex: badly needs fuzzing
#47Any rust lovers out there: Could I ask you do a benchmark comparison and a fuzz comparison. I'd be genuinely interested in the result and if (as you might hope) the Rust::regex is as fast as boost:regex, and never crashes, that would persuade at least me to finally learn some Rust!
You can look at a well known (but not very complete) benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long, the fastest c++ implementation (using re2) takes twice as long. I don't know of a fuzz comparison, but there has been fuzzing done on the rust library without finding anything bad, e.g. see this issue [1]. [0] http://benchmarksgame.alioth.debian.org/u64q/p…
> benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long
With PHP at #2? Doesn't seem credible, or the thing being tested isn't meaningfully language-dependent.
Re: Regex: badly needs fuzzing
#48Another counterexample to the idea that modern C++ written by experts is free of memory safety issues.
This isn't modern c++, but whatever.
Re: Regex: badly needs fuzzing
#49Earlier quoted context omitted.
You can look at a well known (but not very complete) benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long, the fastest c++ implementation (using re2) takes twice as long. I don't know of a fuzz comparison, but there has been fuzzing done on the rust library without finding anything bad, e.g. see this issue [1]. [0] http://benchmarksgame.alioth.debian.org/u64q/p…
> benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long With PHP at #2? Doesn't seem credible, or the thing being tested isn't meaningfully language-dependent.
Indeed, it is the regex implementation that is being tested (and so the language of that implementation is relevant), which is exactly what this discussion is about and also why that comment is careful to be specific about which programs are using which regex implementation.
Re: Regex: badly needs fuzzing
#50Earlier quoted context omitted.
You can look at a well known (but not very complete) benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long, the fastest c++ implementation (using re2) takes twice as long. I don't know of a fuzz comparison, but there has been fuzzing done on the rust library without finding anything bad, e.g. see this issue [1]. [0] http://benchmarksgame.alioth.debian.org/u64q/p…
> benchmark comparison here [0], rust wins, the fastest boost program is c++ g++ #3 and takes 8.5 times as long With PHP at #2? Doesn't seem credible, or the thing being tested isn't meaningfully language-dependent.
It's testing each language's implementation of regexes. A lot of the languages are probably linking in a regex library written in C or C++ anyways. It's evidence that if you're writing something that's heavy on regexes, any slowdown probably isn't due to the language itself but its library implementation.