[Tizen General] 27000 errors in the Tizen operating system
Hello All, This article will demonstrate that during the development of large projects static analysis is not just a useful, but a completely necessary part of the development process. This article is the first one in a series of posts, devoted to the ability to use PVS-Studio static analyzer to improve the quality and reliability of the Tizen operating system. For a start, I checked a small part of the code of the operating system (3.3%) and noted down about 900 warnings pointing to real errors. If we extrapolate the results, we will see that our team is able to detect and fix about 27000 errors in Tizen. Using the results of the conducted study, I made a presentation for the demonstration to the Samsung representatives with the offers about possible cooperation. The meeting was postponed, that is why I decided not to waste time and transform the material of the presentation to an article: https://www.viva64.com/en/b/0519/ Best regards, Andrey Karpov, Microsoft MVP, Ph.D. in Mathematics, CTO "Program Verification Systems" Co Ltd. ___ General mailing list General@lists.tizen.org https://lists.tizen.org/listinfo/general
[Tizen General] Why it is important to check what the malloc function returned
Hello, The absence of nullptr checks after calls to the malloc function is a very common issue in the Tizen operating system and the libraries it uses. I mentioned this in the article "27 000 Errors in the Tizen Operating System" - https://www.viva64.com/en/b/0519/ I also pointed it out in a more detailed analysis of the EFL Core Libraries used in Tizen. The library has almost zero "nullptr checks" after calls to malloc. Here is this article, with the comments by one of the developers included: "Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives" - https://www.viva64.com/en/b/0523/ I finally found time the other day to write a detailed article on the malloc function. There are 4 reasons at once, each of them is enough to prove that it is so necessary to write a check after you call the malloc function: 1. Null pointer dereference is undefined behavior 2. Null pointer dereference is a vulnerability 3. Where are guarantees that dereferencing of exactly a null pointer will occur? 4. Where are the guarantees that memset fills the memory in a direct order? Please do take a look at this article. I hope you will find it interesting and useful. *Why it is important to check what the malloc function returned* - https://www.viva64.com/en/b/0558/ ---- Best regards, Andrey Karpov, Microsoft MVP, Ph.D. in Mathematics, CTO "Program Verification Systems" Co Ltd. URL: www.viva64.com E-Mail: kar...@viva64.com ___ General mailing list General@lists.tizen.org https://lists.tizen.org/listinfo/general
