PVS-Studio Analyzer Spots 40 Bugs In the FreeBSD Kernel 169
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.
ahhhh advertising, my good friend! (Score:2, Insightful)
Re:ahhhh advertising, my good friend! (Score:5, Insightful)
You know, if you want "free" advertising by doing free code analysis against a piece of free software, publish your results openly, and give them the output to the project to actually use to improve that project ... you're bloody welcome to some free advertising.
Depending on the software you write, and what you use it for ... $5k for a development tool isn't that crazy stupid.
One with proven results against a known piece of software and which contributes to eliminate bugs in a provable way and gives those results freely to open source?
Oh, hell yeah, bring on the free advertising for more companies like this. And hopefully people are thinking "holy crap, if they found over a 1000 questionable pieces in the FreeBSD kernel, imagine what they can do with my stuff".
I say kudos to these guys, and any "free" advertising (beyond their time invested and the value of giving back to the FreeBSD project) is deservedly theirs.
Re: (Score:1)
Re:ahhhh advertising, my good friend! (Score:5, Insightful)
LOL ... aww, that's sweet.
So, yeah -- hate corporate douchebags and morons, can't fault anybody who gets product promotion by actually proving the product works and giving the results for free to a high profile bit of free software to make it better. Who knew?
I don't hate the entire world, just huge swaths of it made up of assholes and idiots. The good bits still make me happy, but we seldom see those.
Maybe it's a coherent outrage based on moral principles and reasoned thought? That, or the meds finally worked today, who knows.
Slashdot posts plenty of things which require outrage -- this particular "Slashvertisement" is pretty much the exact opposite. It's showing you have something of value by proving it works, and contributing to something and making it better. If that leads to sales and revenue, best of luck.
So, world -- "philanth-ver-tize" more, and grumpy, bitter old men might say "wow, that's awesome". Go ahead, I fucking dare you to give us a few things to be positive about. ;-)
Cheers
Re: (Score:2)
This demonstrates the power of coffee.
Coffee, making people out of assholes since the 1600's...
Re: (Score:3, Informative)
Depending on the software you write, and what you use it for ... $5k for a development tool isn't that crazy stupid.
Agreed, it's not crazy stupid at all. In fact, I think it's pretty reasonable when you think about it.
For comparison, I remember when JBuilder (the Java IDE) cost at least that much money _per seat_. And that was a long time ago.
And on the advertising topic, this kind of advertising doesn't bother me at all. It's proving the product, factual, and relevant. What more can you ask for?
Re:ahhhh advertising, my good friend! (Score:4, Insightful)
And on the advertising topic, this kind of advertising doesn't bother me at all. It's proving the product, factual, and relevant. What more can you ask for?
That it's not deceptive, but presents itself as advertising. ..." when it's really "We have ..." is deliberately misleading, and I prefer honesty.
Writing "They have already checked
Sure, new powers that be, bring on slashvertisements, as it can be useful, but mark them as such, and avoid astroturfing, with submissions pretending to be an enthused user.
Honesty in advertising - I know, what a concept. But here, I think it would work better. The curmudgeon user base here likely prides itself on never getting to the once in "fool me once, shame on me", but discards anything that smells of deceptiveness or social engineering. Even in marketing.
Re: (Score:2)
They do share the results with the project they analyze. They specifically mention that in every one of these articles they write.
Re:ahhhh advertising, my good friend! (Score:5, Insightful)
I ran the VS2015 built-in code analysis tools, which didn't find the issue but did highlight some dubious looking code in other places which I fixed while I was at it. So there is merit in code analysis, even if it didn't help me in this instance. I eventually found the issue by plastering crt heap debug calls all over until I isolated the place where the corruption happened.
And some code analysis tools have proven to be a total waste of time. I recall using Purify / Quantify in one workplace hoping to isolate a runtime issue where it put so much instrumentation over the code that it took 10x as long to build and ended up crashing for its own reasons. It wasted more of my time than it would have taken to fix the issue without its "help". In my experience the more expensive a development tool is, the more bugs and the less benefit it will bestow from its use - and if it's from IBM then it will be massively expensive and bestow zero benefit.
Re: (Score:2)
Another point is that many of the so-called "safe" methods, e.g. strnc
Re: (Score:2)
Re: (Score:2)
Only $5k? I wish I could buy development tools for my workflow for that cheap.
Re: (Score:2)
That's about how I look at it. Anyone can download the list of the things that the tool found and see for themselves what kinds of issues it was uncovering - the things that it is finding are certainly valid concerns.
What I find interesting about what it did find is that some of the issues are looking at the code formatting as an indication of what was intended, and it is flagging things that seem suspicious and/or inconsistent. Just using a normal compiler isn't going to catch these sorts of things since
Re: (Score:2)
"Depending on the software you write, and what you use it for ... $5k for a development tool isn't that crazy stupid."
I work in a space lab. Spending this kind of money is easily justified on the basis that projects are either long-lived (20+ years) and/or software updates are often difficult (stuff that goes in a spacecraft is hard to do field calls on), so making sure stuff is well written in the first instance saves more than that in the long term.
Perhaps PVS should offer their services to Toyota.
Re: (Score:2)
$5 is bullshit if you're an open source project with 0 funds and a github page.
Oh, I think $5 is manageable, but $5k is a different story.
And if you're a github developer, you might not be using Microsoft Visual Studio, the only thing this tool runs under.
Can't one just analyze the C/C++ code under Windows then? Not necessarily, no. The code may depend on #ifdef paths that are or are not taken under Windows, defining different macros. It will almost certainly have different bits.h and similar includes. That can (and in many cases will) lead to both false positives and missed bugs,
Re:ahhhh advertising, my good friend! (Score:5, Interesting)
If you want something better, there's Coverity. Free if you qualify. If not, it's even more expensive than PVS-Studio, but does a heck of a lot better job.
FreeBSD has been analyzed by Coverity [coverity.com] for years... did it not catch the problems that PVS-Studio found?
Re: (Score:2)
FreeBSD has been analyzed by Coverity for years... did it not catch the problems that PVS-Studio found?
There are over 10,000 outstanding defects in the Coverity scan, so who knows. I'm not going to go through all of them to find out. :-)
Also, Coverity scanning levels might be set to discard "cosmetic" defects or defects that are optimized away, like doing the same tests twice (which appears to be a Big Thing for PVS-Studio) or initializing a variable twice.
Re:ahhhh advertising, my good friend! (Score:5, Informative)
Coverity, along with most static analysers, has problems with false positives. I spent an afternoon wading through the coverity reports in my own code in FreeBSD libc. I found one possible bug (I think that the code was unreachable, but I may have missed something in one of the callers), all of the rest were false positives. Some were trivial to discount - they were simple artefacts of the fact that Coverity works one compilation unit at a time and a cursory glance at the other compilation unit showed that it was not a problem. The others required a bit more digging. In particular, Coverity seemed to be really confused by some reference counting functions.
I've only had time to glance over the PVS results, but they seemed to be more useful.
Re: (Score:2)
Re: (Score:2)
If you just want some basic and free for C code, there's splint. Better than nothing at an unbeatable price.
Unfortunately it's also guaranteed to find at least 20x as many problems as there actually are, so it's only free if the developer time spent weeding out FPs is also free. If you want a free alternative to PVS, go for cppcheck.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
It says in TFA that FreeBSD already runs Coverity, but PVS-Studio found an additional 1000 bugs anyway
You're reading too much into it. It found around a thousand defects, but as far as I can tell, nothing was done to correlate those to the ten times as many defects that Coverity has marked as present and not yet fixed. Checking each and every defect against what Coverity found would be quite a lot of work.
It would surprise me very much if a majority of the 1000 weren't also already discovered by Coverity, and that any surplus that PVS-Studio found and Coverity didn't are mostly false positives.
Re: (Score:2)
You think the FreeBSD foundation has 0 funds and the github page is their primary web presence? Lol....
Re:ahhhh advertising, my good friend! (Score:4, Insightful)
Re: (Score:1)
Re: (Score:3)
Its size of code and users not dev team ... (Score:2)
you're looking at spending about $5k for the product, unless you are a large development team, cost benefit ratio is low
Why? One month of developer time is one month of developer time regardless of the size of the team. Either the product saves that much or more or it does not. If it does it is worthwhile.
As for whether a developer can afford the cost that again is not the function of the team size, rather the popularity of the dev team's product, the number of users. With a sufficiently sized market the revenue or donations would cover the cost regardless of the size of the team.
Re: Its size of code and users not dev team ... (Score:2)
The software provider probably has costs beyond developer time: reputation, customer support, regulatory agencies, legal liability, and/or others. Escaped defects affect those, and the cost to avoid delivering buggy software should factor those savings in.
Re: (Score:2)
Re: (Score:2)
$5K =~ 25-50developer hours.
All SW i work with is either free or costs more than 5K per seat. (I think that the SW licenses used by me should account to about $10k-$20k/year)
If i believe that a tool licensed for as little as $5k helps me in doing my job (and the job of colleagues) more efficiently, the money usually is not the problem.
Re: (Score:2)
It all depends how many people rely on the product, and how important it is to them. If it's a piece of avionics that keeps thousands of airliners flying safely, I'd suggest that $5k is not a lot. In such a case, $5 billion would be money well spent if it made the product significantly safer and more reliable.
Please remember, too, that to many corporate executives $5k is - quite literally - lunch money. Or at least the cost of a good dinner with some "decent" wine.
Re:ahhhh advertising, my good friend! (Score:5, Insightful)
So far every thing I've seen in their analysis is a bug in their software
How far did you read the article? Starting with the second example, they were finding things that were not logically correct.
For example
if ((m->m_flags & M_PKTHDR) == 0 || ...
m->m_pkthdr.len != m->m_pkthdr.len {
That or clause is clearly defective.
and the very first one, rather than being a FreeBSD bug is a style bug that just looks bad, but is working as intended, yet they intentionally mislead by indicating that its a flaw. Its not, its badly formatted, but its working as intended and that if statement is only meant to control the first line.
I disagree. It doesn't just look bad, it's indentation is communicating semantics that aren't accurate. It should be corrected. Something that should be corrected... is a flaw.
You say its "working as intended" (and I presume it is); but the message the developer communicated with that formatting is that he intended for it to work differently from how it does in fact work.
I agree its "just a formatting error"... but its a particularly nasty one; and code like that SHOULD be investigated and corrected.
Re: (Score:3, Funny)
I disagree. It doesn't just look bad, it's indentation is communicating semantics that aren't accurate. It should be corrected. Something that should be corrected... is a flaw.
You say its "working as intended" (and I presume it is); but the message the developer communicated with that formatting is that he intended for it to work differently from how it does in fact work.
I agree its "just a formatting error"... but its a particularly nasty one; and code like that SHOULD be investigated and corrected.
Thank god FreeBSD isn't written in python
Re:ahhhh advertising, my good friend! (Score:4, Interesting)
Having said that, static analysis can be a very useful tool for improving code quality, if (and only if) you understand the application you are looking at.
Re: (Score:2)
It really depends on the type of project. In this case, many of the issues look like merge errors. Someone submitted a patch, someone else merged it at some point and some curly brackets were lost or a comparison was broken or operator precedence was ignored.
I see that sort of thing a lot in projects where there has been a lot of merging, and of course open source projects are often the worst for it. An open source tool that could do this would actually be of great benefit I think. It's a shame they don't d
Re: (Score:1)
Pretty sure they will scan open source code for free, especially if easily accessible like on github.
Re: (Score:1)
and the very first one, rather than being a FreeBSD bug is a style bug that just looks bad, but is working as intended, yet they intentionally mislead by indicating that its a flaw. Its not, its badly formatted, but its working as intended and that if statement is only meant to control the first line.
I disagree. It doesn't just look bad, it's indentation is communicating semantics that aren't accurate. It should be corrected. Something that should be corrected... is a flaw.
You say its "working as intended" (and I presume it is); but the message the developer communicated with that formatting is that he intended for it to work differently from how it does in fact work.
I agree its "just a formatting error"... but its a particularly nasty one; and code like that SHOULD be investigated and corrected.
Exactly. This triggered all sorts of warning bells inside my head because this is one of the ways you hide malicious code in a large software project.
Re: (Score:2)
Even the first example is clearly a bug, it registers the Padlock entropy source if the appropriate VIA CPUID flag indicates its presence, but deregisters it unconditionally. It's impressive that it found that, I don't know of any other tool that would check that.
(Just about to submit a feature request to cppcheck...).
Re: (Score:2)
I disagree. It doesn't just look bad, it's indentation is communicating semantics that aren't accurate. It should be corrected.
A bit like goto fail, which PVS should have caught had it been used on the code.
Its possible that this check in PVS was actually inspired by goto fail, hard to tell without the devs letting us know.
Re:ahhhh advertising, my good friend! (Score:5, Insightful)
Formatting is important - it indicates to human programmers what the *intent* of code is supposed to be, at least in whitespace-neutral languages like C. This doesn't sound like a bug in the analysis software. I would definitely want a product to flag (albeit with low priority) any instances of that sort of misleading indentation in my code, because either it works correctly but looks wrong, or it works incorrectly but looks fine. The former is less serious than the latter obviously, but both should be fixed, IMO.
The rest of the article is worth a read, even if you disagree with the first style-related issues. There are a lot of other issues that can only be definitively labeled as bugs by the BSD developers who know the codes, but if they aren't bugs, they sure look like them. There are cases where both branches lead to duplicate, identical code being executed. There are null pointer checks that come after the pointer dereference. There are flags set that do nothing. There are variables corrupted because operator precedence was misunderstood. Even if some of these happen to work correctly, it's likely only because of chance or it's in rarely exercised code. And worse, fragile code means it's more likely to break in the future when minor changes are made.
All in all, it's a fairly impressive list of finds, at least from an outside perspective. I'd be curious to see how many of these are deemed as bugs by the BSD and get fixed.
Two character comments are good ... (Score:3)
There are variables corrupted because operator precedence was misunderstood.
One of my favorite (not) type of bugs. Because a "two character comment", a pair of parenthesis, would just be awful. Two character to document your intent, which hopefully matches your implementation, but if not may just save you.
BitZtream was wrong. They just fixed it. (Score:4, Interesting)
BitZtream was wrong. A fix has been committed which adds the missing parenthesis. [freebsd.org]
Re: (Score:2)
Because a "two character comment", a pair of parenthesis, would just be awful. Two character to document your intent, which hopefully matches your implementation, but if not may just save you.
If you are documenting your intent then you are doing it wrong. As pointed out, code that is formated correctly (and consistently) should be the documentation of your intent. C and C++ are expressive enough that the source does not need to obfuscate the intent, and comments of the intent can disagree with the code so are really just unnecessary noise.
Comments should document the variables and their inter-relationships. This works both when you are writing bland straightforward code as well as when you ar
Re: (Score:2)
If you are documenting your intent then you are doing it wrong.
The "two character comment" that I am referring to is a pair of parenthesis. The parenthesis are functional, they affect the parsing of expressions. They have a dual role of documenting intent and manifesting that intent in the code. Parenthesis, even when strictly unnecessary and just there for readability (a comment if you will), is "doing it correctly".
Re: (Score:2)
I never understood people who try to minimize the use of brackets. Do they also remove whitespace because it isn't needed, and who cares about readability anyway?
Re:Two character comments are good ... (Score:5, Interesting)
Re: (Score:2)
You can set a prettyprinter to support just about any formatting standard you prefer these deays. (How many spaces in a tab, braces on end of line or separate lines and so on)
I've still not found one that supports my coding style, which uses one tab for each indent level and spaces for alignment (so you can adjust the tab width in the editor and still have correctly formatted code, whatever value you pick). Actually, that's not quite true: one of my students wrote one that did just that (and use the TeX line-breaking algorithm with different penalties for different syntactic features), but it never progressed beyond a student project and then some guys at Google came along and
Re: (Score:2)
Re: (Score:1)
I used to do the same, but now I let it go. I just tab-indent everything and many times things don't line up visually, but I've grown used to it. Makes it easy to quickly format merged or other code snipits.
Re: (Score:2)
Looks like the FreeBSD team disagreed with you, as they modified the if test to bracket in the 2nd statement:
https://github.com/freebsd/fre... [github.com]
Re: (Score:2)
wait WHAT? FreeBSD developers have a coding style that permits, let alone encourages, the indentations not to track the actual structure of their code?
They have a ":ts=4" requirement, unless I am mistaken. Which means that if your tabs indent 8 characters, you are in error when reading it.
Sure, it's better to use spaces instead of tabs, but if your standard says that tabs equivalent a certain amount of fill space, what's default in Visual Studio should have absolutely no bearing on the correctness if you differ from that.
Re: (Score:3)
Fairly certain they were being sarcastic, and allowing code-indent to differ from code-intent would be a style guide violation.
But if not, then I have to agree - I'd be *very* suspicious of that software's quality. Not because I ever intend to look at the code, but because all of the people that *do* regularly look at the code will have a strong tendency to read what the visual formatting says is going on, rather than what the punctuation actually indicates. An invitation to what is gently called "unespec
Re: (Score:2)
Deregistering something that was not registered properly in the first place is often a very dangerous, and incorrect, thing to be doing!
It is a bug, but it's not actually dangerous. The unregister function contains checks that the thing that it's unregistering is registered and silently does nothing if it isn't. If this weren't the case, lots of people would have seen odd behaviour.
Re: (Score:2)
> tabs are important.
They are important to avoid.
Says one who never writes makefiles or Fortran code.
Tabs are specified as whitespace in the C standard, and it's perfectly fine to use them. It may be better to always use spaces, unless space is an issue. If you use them, it's wise to also let viewers know what the max tab size is set to, like
Project default tab size: 4
*/
That way, copying and pasting between files that uses tabs and files that use spaces won't be much of a problem. Good editors shoul
Re: (Score:2)
Says one who never writes makefiles
Makefiles: the greatest argument ever made by mankind that tabs should be forever banned. (Or spaces, either way, but only one sort of leading whitespace should be syntactically legal in any given programming language.)
Re: (Score:3)
Tabs are bloody useful for indentation since people can set the tab width to whatever they want when viewing code. Good luck doing that with spaces.
Re: (Score:2)
Which is fine until you mix tabs and spaces to get that just-perfect indentation of some line, as always ends up happening. (Plus, your editor could set the width of leading spaces to whatever you wanted it to, if it actually mattered).
Re: (Score:1)
Uhm, he works for them, of course his biased, and he has astroturfed for them all along.
https://mvp.microsoft.com/en-u... [microsoft.com]
Or his linked in profile, or anything else as simple google result shows, which is what should have been done if you see his last name and an article touting a Russian name on a website in America (simply because Russians typically use Russian websites just like Americans typically use American websites).
Its just slashdot and timothy is a fucking moron who's too stupid to catch these sort
Re: (Score:1)
Another one? (Score:1)
Re: (Score:1)
Well, it's not very likely that we'll be given a chance to run the analysis on Windows. Even if such a thing happens, we can't write an article about that. In general, we like checking Microsoft projects. These programs are of high quality and it's a big achievement for us to find something worthwhile, as well another opportunity to advertise PVS-Studio.
Here are the articles about our project checks:
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
This isn't the correct forum to publish your perverse sexual fantasies.
Re: (Score:2)
Re: (Score:2)
No, this IS the correct forum to publish your perverse sexual fantasies - have you never read a GNAA post? Or that one about the poopeater?
Re: (Score:2)
Now you made me feel sick :(
Poor Practices by PVS Studio and HexRays (Score:4, Interesting)
PVS Studio is a great application but since they only do team licensing "1-9 developers" I can't see the benefit in buying it, just like IDA Pro. I'm an open source only dev in the C/C++/C# world, all my profitable work is in other languages...
I'd gladly pay a REASONABLE price for all these tools if they'd not only provide proper Linux versions (PVS studio only ever had an internal Linux version...in projects with Linux and Windows specific code it is difficult if not impossible to analyze the Linux parts) but so far since it seems like the real benefit to open source teams who can't afford this software (that is windows only anyway, mostly) is extremely low despite it's utility otherwise.
Re: (Score:2)
It's pretty clearly just a marketing strategy if they're not giving teams access to their tools and their reports.
Re: (Score:2)
Not to mention licensing in a way that makes people able to afford and/or use the software for open source and free software - part of their analyzer uses clang, the least they could do is actually contribute toward that project and the ones that they "analyze."
The tab thing (Score:1)
No the tab thing, he's likely correct on.
if (something is there)
tab1 dinit the something
tab2 close the something
It does look like those two things are supposed to be executed in the if. The close presumably tests the handle and rejects it, so it doesn't fail, but it does need fixed.
On the macro thing, they pass in 10, or 0 to that macro and it ignores it and uses 0. But so what, thats just cleanup if you get time.
It's all very meh! Each change carries a risk, I've seen some of the most obscure bugs introduc
Re: (Score:2)
No the tab thing, he's likely correct on.
if (something is there)
tab1 dinit the something
tab2 close the something
It does look like those two things are supposed to be executed in the if.
Only if you don't have your tabs set correctly according to the standards for the project.
This is perfectly fine: /* ex:ts=4
*/
[4 spaces]if (something is there)
[8 spaces]tab1 dinit the something
[tab]tab2 close the something
It will display with the first and third lines aligned, and the second line indented.
However, if you attempt to read that in an editor that doesn't have modline support and by happenstance defaults to 8 characters fill for tab, it will display as if the second and third line are both inden
Re: (Score:2)
Any sufficiently large and well organised programming team will have a style-guide and instructions for configuring your editor specific to the project. Style checkers will run as part of automated builds to determine non-compliant code, which can be handed to interns as busy-work to correct (with code reviews as per necessary). Developers will be requested to pretty-print their code against an indentation rules file prior to checking in work, which will be available as a command line tool or as an IDE func
Re: (Score:2)
Wrong. To any halfway competent C programmer it "looks like" no such thing. Because he knows that if there are no braces, the if statement always acts on the single following statement.
If it is C, not Python, the indentation means absolutely nothing except a visual cue, and any C programmer who relies only on visual cues is a
Re: (Score:1)
To a competent C programmer, it's obvious what the code *does*.
It's not always obvious what it was *intended* to do. IOW, "is this a bug or not?"
Re: (Score:2)
if (something is there)
tab1 dinit the something
tab2 close the something
While the example is obvious to a competent C programmer, it is NOT obvious what was intended. And that is the very core of why coding style guides are used, and often heavy-handedly required by PMs.
if (condition) {
statement1;
}
statement2;
The deliberate braces (through technically redundant) make it clear what was intended even though statement2 has been indented improperly. I'd expect a static analyzer to f
Re: (Score:1)
Re: (Score:2)
This ought to fix most of that ... :-) (Score:4, Funny)
PVS-Studio detected more than 1000 suspicious code fragments that are most likely bugs or inaccurate code.
Those aren't bugs; that's untested code. (Score:1, Flamebait)
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
Bethesda Softworks (Score:5, Funny)
Somebody get this to Bethesda, stat!
he's way overconfident (Score:2)
Or perhaps during debugging, it was copied, experimental changes were made on one execution path (perhaps just a debug statement), then it was decided the changes weren't all that helpful, and the changes were deleted again, leaving both blocks identical (considered mostly harmless, but ought to have a comment if deliberately left that way).
Re: (Score:3)
Then at minimum you'd expect removal of the check (not a comment), or a history of patches which indicate that it was actually a deliberate omission after testing.
Oh, Karpov, you inveterate spammer... (Score:2, Informative)
Re: (Score:3, Interesting)
You may just say - hey this is me, psychonaut, I've banned viva64 on Wikipedia. Praise me for that. Because of me you won't see links to really helpful material on viva64.
For example, it's really not necessary for those who are interested in Precompiled header [wikipedia.org] to know that there is a super useful article StdAfx.h [viva64.com]. Burn it all! :)
Re: (Score:2)
Re: (Score:2)
You call it "spam", yet every single article from PVS that I've seen anywhere always points out actual code defects in real world projects.
Dear PVD Team: (Score:2)
Re: (Score:2)
See "An always up-to-date list of articles [viva64.com] describing errors that we find in open source projects with PVS-Studio analyzer".
We have checked this projects from the list you've provided:
Re: (Score:2)
Re: (Score:1)
The "recurring check" warning isn't (Score:2)
Because these two blocks of code are not the same (spot the difference). Here is block 1:
static int ....)
.... // <=
....
qla_tx_tso(qla_host_t *ha, struct mbuf *mp,
{
if ((*tcp_opt != 0x01) || (*(tcp_opt + 1) != 0x01) ||
(*(tcp_opt + 2) != 0x08) || (*(tcp_opt + 2) != 10)) {
return -1;
}
}
Here is block 2:
static int ....)
....
....
qla_tx_tso(qla_host_t *ha, struct mbuf *mp,
{
if ((*tcp_opt != 0x01) || (*(tcp_opt + 1) != 0x01) ||
(*(tcp_opt + 2) != 0x08) || (*(tcp_opt + 3) != 10)) {
return -1;
}
}
P.S
Re: (Score:2)
The mentioned in TFA that FreeBSD already uses Coverity.
Correct.
So they've only found things that Coverity missed.
That does not follow. There are over 10,000 defects which Coverity lists for the project which have not yet been fixed or marked as dismissed.
There is likely a substantial overlap between what PVS-Studio found and what Coverity found. Unless going through the results side-by-side, you won't know, but I think this is a reasonable assumption, given that the FreeBSD project doesn't have the resources to follow up on everything Coverity reports.
Re: (Score:1)
This isn't 1980, we can parse identifier names that are longer than 2-3 characters.
You realize that the BSD project dates back to the 1970s, and Unix itself dates back to the 1960s?