[MaxBarraclough]

> You rarely do these in Modern C++.

As I said before, one way or another, undefined behaviour is still a major problem in C++ codebases. This isn't really up for debate. pjmlp provided a good link on this. Most of Chromium's serious security bugs are due to memory safety issues. [0]

> It's your responsibility to check the input of program before doing anything with it.

C++ makes it the programmer's responsibility to avoid undefined behaviour. Programmers are not capable of doing this reliably. We're now at the point that it's no longer credible to argue otherwise. Even after all these decades it's still a problem for C++.

> Structured Exception Handling aka SEH Exceptions can catch things like divide-by-zero, read-before-write, dereferencing null

Sure, and with GCC/Clang, there are equivalent flags to enable trap-on-error for these errors. They're rarely used in production though, so we still face the consequences of undefined behaviour.

> It's your job to know these footguns.

Again, we've seen that C and C++ programmers simply are not capable of avoiding undefined behaviour. Even Google is unable to keep UB out of their prized Chromium codebase, despite their considerable investment.

> It doesn't because overloading depends on the arguments not on the function names

That's the definition of overloading, not a refutation of my point.

In a language like C with no overloading, the function identifier is enough to uniquely identify the function. You don't need to check if there are overloads, the identifier is enough. If you introduce overloading, that property no longer holds. You might work under the mistaken impression there are no other overloads of a function, or it might be non-trivial to determine the types being passed, especially in the presence of type-inference.

It's resolved at compile time, rather than at runtime, but my point stands.

> Without overloading, things become ugly.

It's a tradeoff.

[0] https://news.ycombinator.com/item?id=26862330

[v8dev123]

The thing with memory bugs is that you need another bug for Sandbox to fully exploit the browser.

Here is a real world logical exploit that knock sandbox and Rust won't prevent this stuff,

https://bugs.chromium.org/p/chromium/issues/detail?id=386988

[MaxBarraclough]

> The thing with memory bugs is that you need another bug for Sandbox to fully exploit the browser.

The quote was Around 70% of our high severity security bugs are memory unsafety problems. Doesn't sound like sandboxing is effective there.

> Here is a real world logical exploit that knock sandbox and Rust won't prevent this stuff,

I'm not sure I see your point here. No one is arguing that Safe Rust makes all logic bugs go away. It's not a formal methods framework, it's a safe programming language. If Chromium had been written in Safe Rust (assuming that's practical), presumably at least 70% of its high-severity security bugs would have been avoided.

You're right that they still wouldn't have perfection. The only shot at perfect security is through formal methods, following SeL4, but as things stand, formal methods cannot scale to a problem as large as a modern web browser. Sadly, even TLS is beyond what we can implement with formal methods.

[v8dev123]

> The quote was Around 70% of our high severity security bugs are memory unsafety problems.

This quote simply means there are 70% high severity security bugs and it doesn't implies anything about sandbox.

You can have a use-after-free exploit but it's worthless without a sandbox escape.

Sandboxing is very effective at memory bugs but certainly bad at logical bugs.