[clang-tidy] memory safe C++ subset

Hi all. I’m new here.

I’ve written a library[1] that makes it practical to write (mostly) memory safe C++ code by substituting the potentially dangerous elements of C/C++ (pointers, arrays, etc.) with fast[2] compatible memory safe replacements.

So it may perhaps now be reasonable to adopt a coding standard that bans most of the potentially unsafe elements of C/C++.

Enforcing such a ban would require a set of clang-tidy checks (or something similar) to identify any instances of potentially unsafe elements. I don’t have any experience with clang-tidy development, but I imagine that such a check set should be fairly straightforward for someone that does have experience writing clang-tidy checks. I mean, they wouldn’t have to do any semantic analysis or anything, they would just need to find any instances of potentially unsafe elements. And the set of potentially (memory) unsafe C/C++ elements is finite, right? Off the top of my head:

unsafe C elements:
pointers (including function pointers), arrays, unions, casts, a lot of standard library functions, arguably primitives that allow access to uninitialized state

unsafe C++ elements:
references, a bunch of the standard library elements (smart pointer implementations that allow unchecked nullptr dereferencing, unchecked container implementations), reinterpret_cast<>

Am I missing anything?

As far as I know, this solution provides a degree of memory safety and performance not previously available to C/C++ developers. The next closest option would probably be building with the sanitizers turned on. While that’s a more convenient solution, the results are inferior both in terms of safety and performance [3]. I’m kind of trying to sell it here because I’m hoping someone here will be convinced enough to go ahead and start implementing the checks (to identify instances of potentially unsafe elements). While I would be ready to contribute to the effort, I’m not sure I have the spare cycles (or expertise) to do it myself.

But maybe I’m getting ahead of myself. Do people even subscribe to the premise here? Would such a set of checks be accepted into clang-tidy?

[1] https://github.com/duneroadrunner/SaferCPlusPlus
[2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame
[3] https://duneroadrunner.github.io/SaferCPlusPlus/#safercplusplus-versus-clangllvm-sanitizers

Did you look at the C++ Core Guidelines and the Guidelines Support Library? These have similar goals to yours and are heading towards being official parts of the C++ standard.

David

Yes, ideally the Core Guidelines would have solved the problem. But unfortunately they don’t. Following the Core Guidelines to the letter does not assure that you won’t be accessing invalid memory or dereferencing nullptrs. Right? For some kind of safety assurance, we’re waiting on the completion of the “Lifetime Safety Checker”[1]. If that ever gets completed a lot of the clang-tidy checks will be rendered redundant. As will the Rust language, in essence. I don’t know if/when it will be completed, but some in the field I’ve talked to insist that it will be never. That they are underestimating the difficulty of the problem. I’m not qualified to judge, but the lack of progress updates is concerning.

And without a completed Lifetime Safety Checker, I might go so far as to classify some of the Core Guidelines as just bad programming advice.

Anyway, the SaferCPlusPlus library has the advantage of not being vaporware.

Also, if the clang-tidy checks work out, the next step might to to extend the checks into an automatic translator from (unsafe) C/C++ to memory safe(r) C/C++. This shouldn’t be too much of a stretch, as the SaferCPlusPlus library provides compatible substitutes for the most used unsafe C/C++ elements (except for C++ references which would have to be converted to pointers.)

[1] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/

And without a completed Lifetime Safety Checker, I might go so far as to classify some of the Core Guidelines as just bad programming advice.

Did that come across as a bit harsh? Let me clarify. The goal is of course, complete (memory) safety and optimal performance. You might think of it as the Core Guidelines trying to get as close to complete safety as possible without compromising on performance. SaferCPlusPlus instead takes the approach of trying to get as close to optimal performance as possible without compromising on (memory) safety.

I think that in the era of rampant vulnerability exploits, it’s important that the “safety first” option be available, even if “performance first” option is more “standard”. Don’t you think?