[strcat]

The person who made the mistake leading to the Bluetooth memory corruption bug we found is not at all at fault and neither is whoever reviewed it. It's a hard to spot race conditions leading to use-after-free. It was not immediately obvious what was wrong to us, but we suspected that it was a use-after-free since it usually is and then suspected that it was caused by a race after seeing what looked like a concurrent task being passed data without being passed ownership over the data with the responsibility to free it It's not clear that the function they called runs code concurrency without blocking until it completes, and the language makes writing safe code in extremely complex areas like Bluetooth near impossible. Google is doing a lot of the right things but not going far enough. It's mostly not a developer knowledge or skill issue. It's a tooling issue and we know how to fix these problems in a systemic way. It's viable to secure a small amount of memory unsafe code that's highly audited and receives special attention. It's not viable to write millions of lines of standard C++ without exploitable memory corruption bugs. The in-progress C++ safety guidelines, etc. are highly inadequate and presented as doing more than they actually provide. It's also too inflexible and highly unlikely to be broadly adopted. Rust is also a more usable, more production language that's a lot easier to learn. Rust developers can focus more on avoiding logic vulnerabilities and using the type system to prevent more of those, since there's underlying type/memory safety to build on. C++ doesn't have the foundation to build higher tiers of safely, since it's all built on sand.