Hello, and welcome to C++ Weekly. I am your host, Jason Turner. In this episode I want
to talk a little bit more about safe C++. I think this is an incredibly important topic,
and I've been talking about it a little bit lately, so I really want to kind of break down
the specific issues for you that I think you need to focus on. So be sure you watch this episode.
[Music] Now first of all, again, I'm going to point you to the video description because
there's lots of links to the details that I am going through here, but also t-shirts, swag,
ways to support this channel, my Best Practices book. Yeah, you should definitely check out my
C++ Best Practices book because a lot of this information is in that book and more,
so you should definitely check that out. There are links for print or ebook versions in the
video description below. Okay. So this is your three-step approach to safer C++, and if you
watched the episode on writing C++ "the Right Way" you might have found that all very overwhelming,
like there's just far too many tools available. We are in a golden age of tooling. Let's distill
it down so that you're focusing on the things you need to focus on. I have to take a slight cheat
-there's a step 0 here. Step 0 means that you already have
some sort of testing scenario set up and a continuous integration/build/test environment
already running. This is absolutely critical. The rest of this cannot work without that. Step one -
you need to add basic static analysis, and it's going to go something like this.
First you need to enable warnings as errors, otherwise you have no hope and you will regress
here, which means fix all of the existing warnings, and then the next thing that you're
going to do is make sure that you're building both 'Release' and 'Debug'. This is important because
your compiler does different types of analysis for both release and debug builds, and then we want to
add clang-tidy. Now when you add clang-tidy it is critical to disable the project specific options.
Here's the list of checks you don't want - abseil, you don't want altera, you probably don't want
android unless you're doing Android development. You might be using boost, so go ahead and enable
that. Bugprone you DO want, you DO want the certs, those are security related issues, those
are very important. You probably don't want any of the fuchsia checks, any of the Google checks,
any of the Linux kernel, LLVM, LLVM-libc. Now you DO want modernize.
You probably want performance and readability, although you might end up disagreeing with some
of them, and you want to disable zircon. We want to disable those things because they
don't apply to your project and they are weirdly specific to other projects. ...and then step 5
-increase the warning level that you are currently using. Add more warnings. Go and find warnings.
You might even do something like -Wall on Clang to discover warnings, and then step 6 is GOTO step 2.
This becomes a cycle until you get as much enabled as you can, but it is a relatively
easy cycle. This is something that you can put one team member on while they up your level here,
and you can probably do this for quite a while, to be honest;
but you don't have to do it all at once. This is very simple and approachable for most projects.
Step 2, enable sanitizers for testing. You want to use all of them - address sanitizer,
undefined behavior sanitizer, thread sanitizer, memory... The problem with memory sanitizer is
that it requires the whole library chain to be compiled with memory sanitizer to get the
best results, so we really want to focus on those first ones. So address sanitizer,
undefined behavior sanitizer and thread sanitizer - you want to use all of those during testing.
Now if you are in an unfortunate scenario where you cannot use these during testing, then your
fallback is to be Valgrind and Dr. Memory, and you can call these as wrappers around your test
when they execute. This is also critical. This is how you're going to catch the memory errors
and the undefined behavior errors in your project. Then step 3 is add fuzzing. Now I'm going to keep
bringing this up, because fuzzing finds all of the things that you don't think about. It's
using your library in ways that you would never use it. You need to learn more about fuzzing. If
you're not fuzzing, you need to start fuzzing. There's episodes on this channel about fuzzing.
I'm going to say all user-facing APIs should be fuzz tested in some way, and just to try to drive
this point home a little bit more, I'm going to mention OSS-Fuzz, which is a project from Google
that is continuously fuzzing a large selection of libraries, and it can support C, C++, Rust, Go,
Python... This really isn't something for just C++ code, but we are a little bit more open to memory
errors than the rest of the world here, so it is pretty important that we do this. As of June 2021,
OSS-Fuzz has found over 30,000 bugs in 500 open source projects. That is a lot of projects,
and, well, you can if you want to check out all of the things that it's doing. It is continuously
testing all of these libraries with new and novel inputs - absolutely critical. So this is your easy
three-step approach to writing safer C++. This is really it. Now step 0, I do assume you already
have tests. Step 1, you add basic static analysis and keep ratcheting up as you can. Step 2,
enable all of the sanitizers for your testing. If you can't do sanitizers, fall back to Valgrind and
Dr. Memory; and then add fuzzing and fuzz testing to your library and work this into your continuous
integration and build test environment. All of this hinges back on having some sort of
continuous integration environment. They all rely on the continuous integration environment.
So hopefully you learned something in this episode of C++ Weekly. Be sure to subscribe,
thumbs up, leave a note. Now I know because I already did the longer version of this episode,
which hopefully you've already watched, that there's a lot more to talk about here,
but I really wanted to make this approachable so that you weren't overwhelmed and said,
"Nevermind, there's far too much here. I'm not even gonna bother." No,
this is your easy three-step approach that your project needs to be doing today. So again,
thanks for watching. Leave a thumbs, up leave a comment. Catch you in the next episode.
[Music]