More and more users of the PVS-Studio C# analyzer get interested in the possibility to utilize it for checking C# code on Linux and macOS. Today the PVS-Studio team has some good news.
Sometimes it seems that things have gone relatively quiet on the year-2038 front. But time keeps moving forward, and the point in early 2038 when 32-bit time_t values can no longer represent times correctly is now less than 21 years away. That may seem like a long time, but the relatively long life cycle of many embedded systems means that some systems deployed today will still be in service when that deadline hits. One of the developers leading the effort to address this problem is Arnd Bergmann; at Linaro Connect 2017 he gave an update on where that work stands.
As is probably known to our readers, PVS-Studio static analyzer is exploring a new development direction – the Linux platform; as you may have noticed from the previous articles, it is doing well. This article shows how easily you can check a project with the help of the Linux version of the analyzer, because the simpler PVS-Studio for Linux is, the more supporters it will have. This time our choice was the CodeLite project. CodeLite was compiled and tested in Linux. Let’s see what results we got.
About two months ago I wrote an article about the analysis of GCC using PVS-Studio. The idea of the article was as follows: GCC warnings are great, but they’re not enough. As proof of my words I showed errors that PVS-Studio was able to find the GCC code. A number of readers have noticed that the quality of the GCC code, and its diagnosis, aren’t really great; while Clang compiler is up to date, of high quality, and fresh. In general Clang is awesome! Well, apparently, it’s time to check LLVM project.
We checked Chromium more than once before, and those who follow our blog could reasonably ask, “Why another check? Weren’t there enough of them?” Sure, Chromium’s source code is particularly clean, which was shown by each of the previous checks, but new errors inevitably continue to appear. Repeated checks prove that the more often you use static analysis, the better. A good practice is to use the analyzer every day. An even better practice is to analyze the new code right after you finish writing it (automatic analysis of recently modified code).
Our team decided to analyze the Linux kernel with our static code analyzer. The difficulty of this task makes it especially interesting. Linux source code has been checked, and is still checked, by a number of different tools. So, finding anything new was hardly probable. Still, we managed to find quite a number of bugs.
Even the most experienced programmers aren’t able to remember all CSS properties or a correct way to write all commands. That’s why it’s always useful to have a cheat sheet at hand in the bookmarks of a browser.