C *

Static code analysis allows you to identify and eliminate many defects at an early stage. Moreover, it's possible to detect dormant errors that don't show themselves when they appear. They can cause many problems in the future and it requires many hours of debugging to detect them. Let's look at an example of such a dormant error.

We, the PVS-Studio static code analyzer developers, have a peculiar view on beauty. On the beauty of bugs. We like to find grace in errors, examine them, try to guess how they appeared. Today we have an interesting case when the concepts of length and size got mixed up in the code.

Static analyzers' primary aim is to search for errors missed by developers. Recently, the PVS-Studio team again found an interesting example proving the power of static analysis.

We describe the implementation of a custom Domain Name System (DNS) by using C socket programming for network communication, together with SQLite3 database for the storage of Internet Protocol (IP) for Uniform Resource Locator (URL). Then we provide a performance analysis of our implementation. Our code is available publicly [1].

__int128 add1(__int128 a, __int128 b) {
    return b + a;
}

Somehow, it so happens that we write about our diagnostics, but barely touch upon the subject of how we enhance the analyzer's internal mechanics. So, for a change, today we'll talk about a new useful upgrade for our data flow analysis.

Most influential programmers say that code must be self-documenting. They find comments useful only when working with something uncommon. Our team shares this opinion. Recently we came across a code snippet that perfectly proves it.

Users sometimes ask how new diagnostics appear in the PVS-Studio static analyzer. We answer that we draw inspiration from a variety of sources: books, coding standards, our own mistakes, our users' emails, and others. Recently we came up with an interesting idea of a new diagnostic. Today we decided to tell the story of how it happened.

Having only programming background, it is impossible to develop software in some areas. Take the difficulties of medical software development as an example. The same is with music software, which will be discussed in this article. Here you need an advice of subject matter experts. However, it's more expensive for software development. That is why developers sometimes save on code quality. The example of the MuseScore project check, described in the article, will show the importance of code quality expertise. Hopefully, programming and musical humor will brighten up the technical text.

In our articles, we regularly repeat an important idea: a static analyzer should be used regularly. This helps detect and cheaply fix many errors at the earliest stage. It looks nice in theory. As we know, actions still speak louder than words. Let's look at some recent bugs in new code of the Blender project.

You may have already read a recent article about the first PVS-Studio run and filtration of warnings. We used the GTK 4 project as an example. It's about time we worked with the received report in more detail. Our regular readers may have already guessed that this article will be a description of errors found in the code.

One of our readers recommended paying heed to the Espressif IoT Development Framework. He found an error in the project code and asked if the PVS-Studio static analyzer could find it. The analyzer can't detect this specific error so far, but it managed to spot many others. Based on this story and the errors found, we decided to write a classic article about checking an open source project. Enjoy exploring what IoT devices can do to shoot you in the foot.

For some people, the introduction of a static analyzer into a project seems like an insurmountable obstacle. It is widely believed that the amount of analysis results issued after the first run is so large that only two options seem reasonable: do not mess with it at all or refocus all people on fixing warnings. In this article, we will try to dispel this myth by implementing and configuring the analyzer on a GTK project.

I strain to make the far-off echo yield
A cue to the events that may come in my day.
(‘Doctor Zhivago’, Boris Pasternak)

I’ll be honest: I don’t write in pure C that often anymore and I haven’t been following the language’s development for a long time. However, two unexpected things happened recently: С won back the title of the most popular programming language according to TIOBE, and the first truly interesting book in years on this language was published. So, I decided to spend a few evenings studying material on C2x, the future version of C.

Here I will share with you what I consider to be its most interesting new features.