Slashdot Mirror
PVS-Studio Analyzer Spots 40 Bugs In the FreeBSD Kernel
Andrey_Karpov writes: Svyatoslav Razmyslov from PVS-Studio Team published an article on the check of the FreeBSD kernel. PVS-Studio developers are known for analyzing various projects to show the abilities of their product, and do some advertisement, of course. Perhaps, this is one of the most acceptable and useful ways of promoting a proprietary application. They have already checked more than 200 projects and detected 9355 bugs. At least that's the number of bugs in the error base of their company.
So now it was FreeBSD kernel's turn. The source code was taken from GitHub 'master' branch. Svyatoslav states that PVS-Studio detected more than 1000 suspicious code fragments that are most likely bugs or inaccurate code. He described 40 of them in the article. The list of warnings was given to the FreeBSD developer team and they have already started editing the code.
A couple of words for programmers who are still not familiar with PVS-Studio. PVS-Studio is a tool for bug detection in the source code of programs, written in C, C++ and C#. It performs static code analysis and generates a report that helps a programmer find and fix the errors in the code. You can see a more detailed description of the tool on the company website and download a trial version.
So now it was FreeBSD kernel's turn. The source code was taken from GitHub 'master' branch. Svyatoslav states that PVS-Studio detected more than 1000 suspicious code fragments that are most likely bugs or inaccurate code. He described 40 of them in the article. The list of warnings was given to the FreeBSD developer team and they have already started editing the code.
A couple of words for programmers who are still not familiar with PVS-Studio. PVS-Studio is a tool for bug detection in the source code of programs, written in C, C++ and C#. It performs static code analysis and generates a report that helps a programmer find and fix the errors in the code. You can see a more detailed description of the tool on the company website and download a trial version.
So basically you want some asstastic shithole style for your source code that no one else wants and you suck at reading C code?
You completely lose EVERY ounce of credibility when you decide that tabs are important.
You also show your typical ignorance by bitching about tabs and being one of those morons who thinks all code should look like you want it to look in whatever shitty editors you use that don't actually handle tabs correctly.
In short, your just another useless douche who thinks his way is the only way. Don't worry, FreeBSD devs and users are confident in the OS enough to not really be upset by what causes you so much butthurt.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
How the fuck are you so sure that the code in question is "working as intended"?
For MOD_LOAD, random_source_register(&random_nehemiah) is only called under very specific circumstances.
Yet for MOD_UNLOAD, random_source_deregister(&random_nehemiah) is called even if random_source_register(&random_nehemiah) wasn't called during MOD_LOAD.
Deregistering something that was not registered properly in the first place is often a very dangerous, and incorrect, thing to be doing!
Oh, and guess what? A FIX WAS JUST FUCKING COMMITTED FOR THE BUG THAT YOU INCORRECTLY CLAIMED DIDN'T EXIST!
You should apologize to all of us for your snide, and incorrect, bullshit.
None of the thirty checks that I just read about it are checks for bugs. They are all checks for untested code.
Every one of those "problems" -- and they are almost all simple mis-types -- are easily spotted by the very first time the developer tests that line of code.
Ultimately, I'm sure it's a very valuable tool for a company with developers who never test the code that they write.
On the other hand, since I test every line of code that I write, often as I'm writing it, it can't possibly test the bugs that I wind up producing -- which are all interactive bugs across features.
Of course, I ain't in C.