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

[Noah L via cfe-dev]

> 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?


On Fri, Jan 27, 2017 at 10:00 AM, Noah L <duneroadrunner at gmail.com> wrote:

> 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/0d37f64a/attachment.html>