<div dir="ltr">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.<br><br>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.<br><br>Anyway, the SaferCPlusPlus library has the advantage of not being vaporware.<br><br>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.)<br><br><br>[1] <a href="https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/">https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/</a><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 27, 2017 at 9:11 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 27 Jan 2017, at 16:48, Noah L via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>