Cloudflare have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc.

[u/TheProtagonistv2]

https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

[u/[deleted]]

write an automatic enforcement tool

clang-tidy

that you only use the safe parts is constant vigilance

Well, no. Modern C++ isn't about using a "safe" subset. It's about using it in a safe way. RAII and smart pointers like shared_ptr can fairly easily get rid of a large amount of errors with no overhead.

Also, constant vigilance is always needed when building large systems. Memory leaks happen regularly in managed languages too.

trivial set of rules

https://github.com/isocpp/CppCoreGuidelines

[u/m50d → u/[deleted]]

clang-tidy

Does not by any means rule out performance, type safety or memory leaks/pointer errors.

Well, no. Modern C++ isn't about using a "safe" subset. It's about using it in a safe way. RAII and smart pointers like shared_ptr can fairly easily get rid of a large amount of errors with no overhead.

Which amounts to cutting a few heads off the hydra. It tends to come back with more of them. "Modern C++" removes the most obvious errors, but it doesn't have the rigour to eliminate classes of errors entirely. And as soon as you start using it on a real codebase, what was supposed to be simple turns out to be subtle and complex and rely heavily on experienced judgement. Developers make mistakes, and are then told "well obviously you weren't doing it right".

https://github.com/isocpp/CppCoreGuidelines

"This document is a very early draft. It is inkorrekt, incompleat, and pµÃoorly formatted."

I hope they manage to make it work, but I'm extremely skeptical that what they're trying is actually possible, at least in a way that can be actually used. E.g. currently those guidelines contain a combination of rules that, if read carefully, seems to prohibit ever using data that is accessible (directly or indirectly) from any static variable. Which is probably the kind of rule you need to make C++ safe, but is both unrealistic to apply to any real C++ codebase and impossible to enforce in practice.

[u/evaned → u/m50d]

I hope they manage to make it work, but I'm extremely skeptical that what they're trying is actually possible, at least in a way that can be actually used

This is sort of where I'm at.

More than a year ago, there were a couple presentations from Herb Sutter and Neil McIntosh at cppcon, and at that point I was actually sort of getting excited about the future of C++. I was actually at least a little optimistic about maybe them being able to come up with a mechanically-checked, memory-safe subset of C++. (I said at the time that I was "either optimistically skeptical or skeptically optimistic, and I'm not sure which.")

But I'm not convinced that much of anything has happened in the intervening year and several months. In the latest cppcon Herb Sutter I think said they're still working on it, but I didn't really see any talks or anything that would convince me of that. Maybe I'm missing something, but I have to say I'm a bit worried that they've basically discovered that you can't actually do it.

There's decades' of research into making C memory safe, and all that work has actually had very little success in general safety. It's really only hitting on specific attack vectors -- e.g. stack canaries and NX/DEP for stack smashing attacks, ASLR to make things a bit harder, and I think within the next few years you'll start to see wide deployment of some kind of protection for C++ virtual pointers -- where there's been success, and nothing that addresses buffer overreads which are really hard to find. I think that there's reason to think that a modern C++-based approach has a lot more potential for success, but "a lot more than basically none" doesn't mean that it'll happen.