Episode 298 of CppCast was recorded on May 5th, 2021. On this episode, Rob Irving and Jason Turner are joined by Loïc Joly, who talks about SonarSource static analysis tools. Also, they discuss Visual Studio 2019 STL, GCC 11.1 updates and Meeting C++ survey results.
This episode is sponsored by a C++ Builder, a full-featured C++ IDE for building windows apps. The idea of choice to build windows applications five times faster while writing less code. It supports you through the full development life cycle to deliver a single source code base. Featuring an enhanced Clang-based compiler, Dinkum or STL and packages like Boost and SDL 2 in C++ Builder's Package Manager, and many more. Integrate with continuous build configurations quickly with MSBuild, CMake and Ninja support either as a lone developer or as part of a team. Thank to almost 20 databases like MariaDB, Oracle, SQL Server, Postgres, and more with Firedocs high-speed direct access. The key value is C++ Builder's frameworks, powerful libraries that do more than other C++ tools. This includes the award-winning VCL framework for high-performance native windows apps and the powerful FireMonkey framework for cross-platform iOS. Test-drive latest version at embarcadero.com.
Rob: Welcome to episode 298 of CppCast! Joining us today is Loïc Joly who is a C++ coder, speaker, teacher, and expert. He represents France on the ISO C++ standardization committee and is also a member of the committee drafting the next version of the MISRA C++ standard for safety-critical systems. In addition to developing in C++, he has a special interest in teaching it and spreading good practices across the community. He is a frequent speaker at meetups and conferences and teaches at Telecom SudParis. Since he joined SonarSource in 2018, he has worked on static analysis for C++, both specifying rules to help other developers and having the fun of implementing them.
Rob: So, this first one is about Visual Studio 2019 16.10 preview, which is out now, I believe. This is their change log announcing that the STL is going to be C++20 feature complete, which is pretty exciting.
Jason: And there's an ironic problem here. There's basically a bug in std::format where one part of it accidentally relies on <locale>. Std::format is supposed to be <locale> independent. They want to change that as a real quick fix to C++20 theoretically. But Microsoft has already promised ABI compatibility with their standard library implementation. So, if they were to fix that in the standard Visual Studio, can't fix it and they would still be stuck with <locale> dependence.
Loïc Joly: To me it's a little bit strange to focus on full library support. What's really matters for me is full support period. But I know it's a good step in there. I'm excited by it.
Jason: Well, they're pretty close though.
Rob: Well, other news we have is an update for GCC 11.1.
Rob: It is being released and they're also announcing a lot of great support for C++20. They're changing their default language version up to C++17, which is great. Did they specify exactly how far along they are with 20 or they're just saying that they're making good progress?
Jason: I went to Cpp reference to look at their version of the compiler support chart for C++20 GCC. They said they're in agreeing for every single language feature except modules. Which is interesting because Clang had the tendency to be ahead on these things. But if you look at this comparison chart right now, GCC and Visual Studio are way ahead of Clang for C++20 support.
Loïc Joly: I've noticed these patterns. I'm even a little bit worried about it because it seems to show that as a kind of slowdown in Clang. It used to be first for language features. I really relied on Clang for my daily work.
Clang is a wonderful tool, but the fact that they are lagging behind Visual Studio and behind the GCC is not a good sign. Right now, for example, for modules, I don't see many stuffs in Clang at all. Even GCC is not complete with modules, but the basic is done.
Jason: I'm just scrolling through this list of comparisons. And some things, like lambdas in unevaluated contexts. It sounds small, but it's huge to library developers. It doesn't even list as partial support in Clang.
Rob: Hopefully, they'll be catching up soon.
Rob: Meeting C++ survey results was a survey on the most popular features of a C++. The founder of Meeting C++, Jens Weller shows last year survey results side-by-side with this year's results. Some have gone down just a little bit, but most of the usage of various features seems to be pretty consistent from year to year.
Jason: One of the main things that stood out to me was that the histograms are almost identical from year to year, which I just really didn't expect. But it's just a couple of little things here. It seems there was more people reporting that they're not using C++14, which is maybe just a different group of people that responded to that question, I don't know.
Rob: Or they're upgrading to the 17.
Jason: I guess maybe they misunderstood the question and they're like, no, I'm not using 14, I'm using 17.
Rob: So Loic, what can you tell us about SonarSource tools
Loïc Joly: So, we have SonarLint, SonarQube and SonarCloud. SonarLint is an IDE extension. And SonarQube and SonarCloud work more in the continuous integration phase. Our tools allow you to analyze your code for doing pull requests, for example, and to block pull requests if it's not meeting some quality criteria. You can also see the story of the code.
Our goal is to be tightly integrated into the development cycle to make a tool for developers.
Rob: Which IDEs does SonarLint support?
Loïc Joly: It supports different IDE depending on the language. For C++ we support Visual Studio. A very few of tools support CLion.
Jason: I'm kind of curious, what kind of tools require full visibility of the project?
Loïc Joly: Like unused functions.
Jason: That's interesting because I just spent a week or so with one of my clients removing about a hundred thousand lines of code, that were unused – considerable performance on that project.
Loïc Joly: It's not so easy to detect that something is not used in C++. It's very tricky because you have some functions that are not used, but you still don't want to remove them.
Jason: Does your tool say that something is completely unused?
Loïc Joly: No. We are not providing a tool to explore your code. We are just focusing on raising issues and trying to explain the issue. So, we are going to show you all the interesting locations that are useful to understand why it's a problem, but we are not providing a tool to manually explore your code base.
Rob: What other languages SonarSource analysis works for?
Loïc Joly: I think we have 27 languages, but the main language we focus is Java. We started as a Java company mostly. So, we are very well-known in the Java ecosystem. And then we also have tools for C#, Python, JavaScript, Apps Script. I think I mentioned the most important ones, and if I forgot some of them, my colleagues are going to kill me tomorrow :).
Jason: Coincidentally, as we were discussing this interview, one of my friends shared with me an issue that SonarQube had found in their C# code base. It was particularly insidious in their code and SonarQube found that.
Jason: Is SonarLint an open-source project?
Loïc Joly: Well, the integration inside of the IDE is open source, but the core of the C++ analyzer is closed source. However, it's available for free. It's also available for free if you do SonarCloud on open-source projects. But if you want to do SonarCloud on a close project, or if you want to do C++ analysis in SonarQube, you have to pay for it.
Rob: So, are there specific types of bugs that the SonarSource analysis tools are particularly good at finding?
Loïc Joly: We have a full range of issues in many different directions. We have a lot of value compared to other tools. We care not only about detecting a bug but rules.
I really think that one differentiating point between our tool and for example, compiler warnings, is that compilers now are doing lots of warnings, very interesting ones but they really try to warn only when the code is almost certainly broken. We try to raise issues when the code is badly written.
So, that's a difference. For example, we have some rules about rule of five or rule of zero. The code could perfectly be correct without following those rules, but it's so much simpler to read code that follows them.
Jason: That's interesting. Just out of curiosity, do you also have rules that try to detect misuse of smart pointers?
Loïc Joly: No, I don't think we have it.
Rob: You've mentioned the Visual Studio plugin, does SonarSource run on Windows, on Linux and Mac as well?
Loïc Joly: The core of SonarSource runs on Windows, Linux and Mac iOS. SonarLint is more for the developer himself. While SonarCloud and SonarQube are more for team. For SonarLint it really depends. For example, I know that for Java it runs on Eclipse and VS Code also, and I don't have the full metrics of which language is supported in which IDE. But basically, we try to support the major ones, obviously.
So, for SonarQube and SonarCloud we have some rules that are going to be followed by the full team. It is going to be shared on each pull request. And in SonarLint there is also what we call a connected mode, which is if you also run SonarQube or SonarCloud, you can synchronize with it.
So that, for example, if in SonarQube you say that a rule is a false positive for you, or if you don't want this rule, we will stop reporting it. So, our tools work together.
Jason: So, you said SonarCloud is available for open-source projects, is that right?
Loïc Joly: Well, it's available for open or closed-source and it's free for open-source without any limitations. If you want to set up SonarCloud or SonarQube, it's a little bit of work to integrate SonarSource into your CI, but once you're used to it, it's just a few lines of script. We have some quick start guides and we have some sample projects that you can look at.
Rob: So, you mentioned in your bio that while working on the stack analysis, you specify rules and helping other developers implement them. What kind of work goes into specifying new rules for the SonarSource analysis tools?
Loïc Joly: Sometimes it's very complex and there are some rules which took us more time to specify than to develop. It may seem surprising, but I even wrote a blog article on one of them.
I'm also going to write a blog article to explain why it's difficult to write a rule. It seems simple, you probably have your own algorithm in your head about what should you do, but if you try to implement this kind of algorithm automatically, then it becomes much more complex.
One interesting part about rules is where we get the inspiration. At first, we need to discover the problem, and then decide how to tune it. When we do something that doesn't work great, we try to remember it so that maybe we write a rule about it in the future. Inspiration for rules comes from experience and from new versions of the standards. So recently we spent some time reading what was new in C++20 and tried to think if it would deserve some new rules.
We also use CppCoreGuidelines as a source of inspiration, but we cannot directly implement rules from CppCoreGuidelines. A big part of CppCoreGuideline requires the user to write the code in a very specific way, which is not the typical way of writing C++.
We are not telling people to write the code in a specific way so that we are going to be able to analyze it correctly. We try to be a tool for all C++ developers, and we work on the existing code.
We also have MISRA, which is a coding standard for the automotive industry mostly, basically it's for safety-critical software. So, it was the current official version of MISRA 2008. It was a different C++ at that time. Now we are upgrading it to C++17. I don't know exactly when it's going to be out, but we try to modernize rules, applicable in every situation because safety-critical code requires extra caution. Some of the rules could be generic. Some of them are probably going to be specific for safety-critical software.
Rob: So, if you're using any of the SonarSource analysis tools against your codebase, do you have a choice to MISRA, the Core Guidelines, or whatever else?
Loïc Joly: We have some flags on the rules that explain where they come from. We have the possibility to create some rule set. But now we don't have the full coverage of MISRA C++ 2008, and we didn't think it was interesting to develop this full coverage. We work on the next version of MISRA. We have basically one profile – Sonar way, which is the set of rules that we believe should be applicable in all circumstances.
When we do a rule, we test it on 30 or 50 open-source projects. We ran it on LibreOffice, on Clang, and on the Linux Kernel. We run it on many big open-source projects, and we try to see the results.
Jason: So, when users set a rule to be ignored on SonarCloud, do you keep those statistics and say – Hey, there's like a hundred thousand users that are all ignoring this rule. Maybe we need to take a closer look at it.
Loïc Joly: We are starting to get this kind of feedback from the users. But at first, we had to make sure that by doing that, we are not sharing secrets of the customers. So, we must be careful about what information we collect. We introduced lots of efforts about rules around security.
Jason: That could be so fascinating to look at that because on one hand you want to be like – a thousand people are ignoring this, they clearly can't all be wrong, but then sometimes I'm guessing you're going to look at it and be like – wow, a thousand programmers are dead wrong!
Loïc Joly: I know they made an experiment for some embedded software. They add the requirement that the software had to be developed twice and ran twice in two different parallel hardware system just to make sure that it was rock-solid. And those teams that developed the program had an obligation not to talk with each other. In some cases, they discovered that there was the same bug at the same place.
Jason: Wow.
Rob: You did mention some newer security rules for C++, what are some of those newer rules?
Loïc Joly: For security one of not so complex to develop but I think quite interesting rule was one about using memset_s to try to delete some memory. Even if someone gets access to the memory, they will not see a password that could be stored there.
We also have a bunch of rules around the POSIX functions, which are mostly for C because it's so much easy to make a buffer overflow in C than in C++. We have lots of POSIX functions, that work for char*, and that text to arguments, a buffer and a size.
It's impossible to be perfect in those cases, but we try to improve. Also, we are going to try to improve on the way where we report the issue to the user. We have this rules that try to detect when you are using some POSIX functions in a wrong way, and you might have a buffer overflow. We also detect if people use the wrong API.
Jason: Wow. Some of those sound like really advanced.
Loïc Joly: Yeah. Probably, when we solve all these problems, I'll be retired. Now we have some things that give some good results, but we still have lots of ways to improve.
Jason: You said you use the Clang static analyzer for the backend. So, if I run my project on SonarCloud, am I going to get all the Clang-Tidy rules as well as your rules? Or are you going to run just your rules?
Loïc Joly: We are based on Clang, but we don't integrate everything from Clang IDE. We designed the rules ourselves. We looked at every source possible, of course, but we didn't just copy-paste Clang IDE.
Jason: If I get a rule violation from one of your tools, how much information am I going to get? You said, a lot of the rules are inspired by the Core Guidelines. I'm just curious, if I get a rule violation, am I going to get documentation that explains why this is a bad idea.
Loïc Joly: Basically, for every rule, we have documentation where we try to explain why we have the rule. Then we almost always have an example of bad code and an example of how to rewrite the code so that it's better. If the rule is inspired by some external sources, like CppCoreGuideline or MISRA, we are referencing them. The rule is located at one place in the code, but we also try to reference other places of the code that are interesting to understand why the rule is triggered.
Rob: Well, look, it's been great having you on the show today. Obviously, people can go and check everything out at sonarsource.com. But where can listeners find you online? Are you on Twitter or blog or anything like that?
Loïc Joly: Well, I'm old school. I don't have Twitter. I have a few blog articles into the blog of SonarSource. People contact me by mail. That's the main way to do it. I mean, that's the way it worked in the nineties. Why shouldn't it work again today? :)
Rob: Alright, we'll include those links to your blog and everything on the podcast resources. Thanks for coming on.
Loïc Joly: Thank you.
Rob: Thanks so much for reading in, as we chat about C++.
We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback@cppcast.com. We'd also appreciate it if you can like and follow CppCast on Twitter. You can also follow me at @robwirving and Jason at @lefticus on Twitter.
We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com/CppCast. And of course, you can find all that info in the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.
Podcast
News
Links
Sponsors
We'd like to remind you that you can use the PVS-Studio plugin for SonarQube. In this case, PVS-Studio becomes an extra data source of errors and potential vulnerabilities. As for SonarQube, it is a convenient tool that allows you to handle warnings issued by different tools. Check out the documentation link: "Integrating PVS-Studio Analysis Results into SonarQube".