
About a week ago on Habré, I published an article "
Three Interviews about Static Code Analyzers ", in which the views of experienced programmers from Acronis, AlternativaPlatform and NPO Echelon about software development were presented to the reader’s court, as well as some of their thoughts on using static code analyzers.
Since the sponsor of the article was the company “Program Verification LLC” - the developer of the
PVS-Studio static analyzer — I decided to ask Andrei Karpov (Technical Director) to also answer some questions. Namely - comment on the interesting moments of all three interviews. Plus make an appeal to colleagues and readers. This is an interesting result.
')
Comment on the remarkable moments in an interview with Acronis
A couple of times at the conference, while informally communicating in the lobby or at the dinner table, I was asked: “Does anyone else program in C ++?”. And sincerely surprised when I answered: "Yes, and this is one of the most used languages." He just somehow today is not on hearing. Around php, ruby, go. It seems that C ++ is "it was a long time and not true." And I am pleased that people will once again see in the article that, for example, Acronis Backup is written in C ++ and 70 programmers are constantly working on it. I myself do not worry about the future of C and C ++. I just wonder how it turns out that many consider C ++ a dead language.
It was also nice to hear that Code Review is widely used in Acronis. Often this method of improving the quality of programs is underestimated, or it is believed that it takes too much time. Miser pays twice.
By the way, I know at least one example, when sometimes multiplying sizeof by sizeof still makes practical sense. For example, such multiplication is obtained when one sizeof () is used to take the number of elements in an array. This is meant:
template <typename T, size_t N> char (&ArraySizeHelper(T (&array)[N]))[N]; #define arraysize(array) (sizeof(ArraySizeHelper(array)))
Such a 'arraysize' protects against an accidental transmission as an argument not of an array, but as an ordinary pointer. Details
here .
As a result, a construction of the form: “sizeof (float) * (sizeof (ArraySizeHelper (array)))” may well turn out. But the PVS-Studio analyzer knows about such cases and does not issue warnings.
Comment on key points in the Alternative interview.
I am not familiar with Java, so I can not comment on how well the language protects against errors. Of course, the mere absence of manual memory management makes life a lot easier. However, I think some of the errors do not depend on the language. For example, if these are
Copy-Paste results . I think using a static analyzer to search for typos would be very appropriate for Java. But again, I don’t know what existing code analyzers offer for Java.
Comment on remarkable moments in the Echelon NGO interview
Immediately felt a little breech writing style text. Apparently, it leaves an imprint on the specifics of the work and the type of documents that have to be prepared. On the one hand, I do not like such texts, as they are boring to read. On the other hand, I envy. The text produces a sense of solidity and seriousness of the work being done. We have no such thing about PVS-Studio. We write a lot of articles about using PVS-Studio, but almost nothing about the analyzer itself and how important it is. It will also be necessary to try peeing up solid descriptive texts about PVS-Studio.
By the way, taking this opportunity, I wanted to raise this topic. Our users or potential users absolutely do not consider PVS-Studio as a tool capable of finding vulnerabilities. I do not understand this. Yes, we are not looking for bookmarks in the code. We are focused on finding bugs, not defects, that make software vulnerable. But still, I do not understand such a division into white and black. After all, many errors can be exactly the same as a vulnerability. Just look at the error from a different angle.
Let's take, for example, the UltimateTCPIP project and find the following error with it using PVS-Studio:
char *CUT_CramMd5::GetClientResponse(LPCSTR ServerChallenge) { ... if (m_szPassword != NULL) { ... if (m_szPassword != '\0') { ... }
V528 It is odd that the pointer to the 'char' type is compared with the '\ 0' value. Probably meant: * m_szPassword! = '\ 0'. UTMail ut_crammd5.cpp 333
We talk about such a mistake simply as a typo. Forgot your pointer change. As a result, it does not check that the string is empty. The code should have been like this:
if (*m_szPassword != '\0')
But then, on the other hand, this is a real vulnerability. Let us leave aside the question of whether this vulnerability can be exploited and how dangerous it is. The main thing is that checking for a typo can reveal the most real security hole. You never know what goes wrong if the program starts working with an empty password.
Or another example from PostgreSQL:
char * px_crypt_md5(const char *pw, const char *salt, char *passwd, unsigned dstlen) { .... unsigned char final[MD5_SIZE]; .... memset(final, 0, sizeof final); .... }
V597 The compiler couldn’t delete the memset function call, which is used to flush the final buffer. The RtlSecureZeroMemory () function should be used to erase the private data. pgcrypto crypt-md5.c 157
Here, PVS-Studio detects that the array 'final' is not zeroed before exiting the function. Why so, it is possible to learn from the description of diagnostics
V597 .
So it’s not clear to me why the diagnostics of PVS-Studio are “insufficiently detecting vulnerabilities”.
Your vision regarding the future of static code analyzers
In general, with static analysis, everything is fine. Tools in this direction are developing rapidly and gaining great popularity.
I would like it to happen more quickly in Russia. We have practically no market for static analysis tools. This can be judged at least by the number of visits to our site, downloading demo versions and sales statistics. Half of all activity is created by visitors from Russia. But the number of Russian customers is not 50%, but only slightly. Sadly
Appeal to readers and colleagues in the shop
Text in the spirit of “use static analysis in the work” will sound trite. Therefore, I will raise a non-standard topic.
I wish you successful communication between superiors and subordinates. Often instructions of the administration look at least strange. But it should be borne in mind that the head often has a large amount of knowledge on the project as a whole. And what seems strange to a subordinate at a high level can be very useful or just forced. Unfortunately, programmers' heads themselves often come from programmers and therefore they are introverted. In other words, setting the task, they do not consider it necessary to explain why all this is necessary. They need to understand and forgive. And then, asking questions, to understand what caused such a strange order. Most likely, the head will not mind to explain. He simply forgot about it or “optimized” the time of communication, reducing the complex task to “do so.” Accordingly, I wish the management not to forget to explain their steps and decisions.
And thanks to the organizer of the interview.
Conclusion
So, dear readers, we can say that bonus materials have just been demonstrated to you. The author hopes that you were interested. On this, allow me to bow out. Write a quality code and use the widest range of useful tools. All the best! We do not say goodbye.