[cfe-dev] [clang-tidy] memory safe C++ subset

Noah L via cfe-dev cfe-dev at lists.llvm.org
Fri Jan 27 10:00:48 PST 2017


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/


On Fri, Jan 27, 2017 at 9:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 27 Jan 2017, at 16:48, Noah L via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
> >
> > 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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170127/b58998c7/attachment.html>


More information about the cfe-dev mailing list