I've seen it too but as a bunch of other people pointed out, the C++ in this library is not the C++ that sort of sentiment is about. This seems like the criticism you should be responding to.
Boost is peer-reviewed and receives more scrutiny than most C++ in the wild. Its peer review is its major selling point, in fact.
> Oh come on, you can't be serious given your advocacy for Rust.
I think it's possible for me to be able to express opinions in favor of memory safe programming languages in general (which is what I'm doing here) while also having worked on one.
If someone were to say "this illustrates why you should use Go for untrusted regexes", I'd agree with them!
Let's talk about the state of security back then if you want and compare.
The disappointing thing in this is that they haven't done a security review and put a plan in place for handling security. Par for the course in the world of software development, sadly.
Well, I have seen exactly that sentiment. But, more importantly, this isn't exactly an obscure memory safety issue. It's a huge collection of flaws that showed up the instant Dmitry Vyukov threw a fuzzer at it. It's not just "all expertly-written C++ is free of memory safety issues" that this is a counterexample to: it's also a counterexample to "most C++ written by experts doesn't have memory safety issues that matter in practice".
> I find that to be gratuitous and petty, and not a good representation of Rust, however.
I haven't brought up Rust here. You can eliminate the memory safety issues by writing in Go, or Java, or C#, etc. etc.