Slashdot Mirror

← Back to Stories (view on slashdot.org)

PVS-Studio Analyzer Spots 40 Bugs In the FreeBSD Kernel

Posted by timothy on from the branching-dancing-regexes dept.

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.

169 comments

  1. ahhhh advertising, my good friend! by muphin · · Score: 2, Insightful

    you're looking at spending about $5k for the product, unless you are a large development team, cost benefit ratio is low

    --
    It's not a typo if you understood the meaning!
    1. Re:ahhhh advertising, my good friend! by gstoddart · · 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.

      --
      Lost at C:>. Found at C.
    2. Re:ahhhh advertising, my good friend! by phantomfive · · Score: 0

      Wow, I think that's the most positive post I've ever seen you write.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:ahhhh advertising, my good friend! by vux984 · · 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.

    4. Re:ahhhh advertising, my good friend! by Dutch+Gun · · 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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    5. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      not if you care about your work being bug free.

    6. Re:ahhhh advertising, my good friend! by Anonymous Coward · · 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?

    7. Re:ahhhh advertising, my good friend! by arth1 · · Score: 1

      $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, which means the product just can't be trusted. Which you can tell from the "bugs" the authors claim to have found in BSD and Linux code, which aren't, in fact, bugs at all.
      A human can certainly spend time on eyeballing the finds for false positives after scanning, but you can do nothing about bugs that were missed due to the architecture differences.

      If you just want some basic and free for C code, there's splint. Better than nothing at an unbeatable price.

      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.

      If you are Windows developer, and fall between those two, sure, it may be worth a look. But it's not a silver bullet, and paying someone $5k to spend a couple of weeks poring over the code for bugs might be just as fruitful.

    8. Re:ahhhh advertising, my good friend! by arth1 · · Score: 3, 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.
      Writing "They have already checked ..." when it's really "We have ..." is deliberately misleading, and I prefer honesty.

      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.

    9. Re:ahhhh advertising, my good friend! by gstoddart · · 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

      --
      Lost at C:>. Found at C.
    10. Re:ahhhh advertising, my good friend! by arth1 · · Score: 1

      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.

    11. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      That it's not deceptive, but presents itself as advertising.

      Agreed - that's a fair point.

    12. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Like you would ever even look at the source code of an operating system.

      But anyway if it bugs you, maybe run it through a white space collapsing program before you build it. That way it's just one long string of text with just 1 space separating everything. Like I said, you will never look at it, so why do you care. And the people who DO look at it have adopted a style that suits them.

      In short, fuck off. And I hope the door DOES hit your ass on the way out, and I hope it hurts because you're an idiot, a bad person, and nobody likes you, and you deserve it.

    13. Re:ahhhh advertising, my good friend! by Lunix+Nutcase · · Score: 1

      They do share the results with the project they analyze. They specifically mention that in every one of these articles they write.

    14. Re:ahhhh advertising, my good friend! by Vertigo+Acid · · Score: 2

      You think the FreeBSD foundation has 0 funds and the github page is their primary web presence? Lol....

      --
      Beta is bad enough to make me go edit settings like this sig that haven't been touched since I joined
    15. Re:ahhhh advertising, my good friend! by Vertigo+Acid · · 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

      --
      Beta is bad enough to make me go edit settings like this sig that haven't been touched since I joined
    16. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      rather than being a FreeBSD bug is a style bug that just looks bad, but is working as intended

      But it clearly isn't working as intended.

      The programmer INTENDED for two commands to run if a statement is true, and that is not what happens. Only one command runs if the statement is true, and the second command always runs.

      Just because only that first statement running if it is true and the second statement always running results in a working program, it's obvious from the tab indent that the program was NOT supposed to function at all. Since it does function, it is not being broken like the developer intended.
      (It may in actuality do what the developer thinks he wants, but unfortunately that isn't what the developer SAID he wants, so it is still incorrect)

      Also how the fuck do you consider two open but only one close bracket to be correct in any way? It won't even compile, how is that working?

      Again, why put an:
      if (var == 0) {}
      test when var will never be defined or set to value? The IF is completely unneeded, just remove the whole thing since it will never ever execute.

      Similarly you should remove all the "if (true) {}" statements from your code and just put the statements right there. Implying they should run sometimes and not others but intentionally stating it will always or never run is clearly not what the developer intended either.

      Lastly, why do you feel putting multiple return statements with different return codes right after each other is correct?


      moo() { ...
          return 0;
          return 1;
      }

      That code also doesn't function either how the developer wants OR how the developer said!
      The developer claims a return code of 1 should be possible, but the code clearly shows it is impossible.

      Thank god you aren't a developer working for me, and I hope I never have to use any software you have ever touched in your life!

    17. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Posting anon so as to not undo mods... I wasn't aware that there was an avenue to obtain/use Coverity for free - what is that? Educational? Also - ever used Gimpel's PC-lint? For $395, it finds /lots/ of stuff that most people (and many tools) miss.

    18. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Please type the line the way you think it should look. Thanks.

    19. Re: ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Cppcheck (FOSS that does static analysis) did the same but story was not accepted to Slashdot. I don't complain nor care that much. Just wanted to point out that you also need either luck or money. Torvalds himself actually wrote a comment about one of the findings Cppcheck made from the Linux kernel but at the time Cppcheck was not famous enough for anyone to catch that. Usually everything Linus says goes to Slashdot.

    20. Re:ahhhh advertising, my good friend! by Immerman · · Score: 2

      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 "unespected behavior" lest hearing it's true name drive you mad.

      Set the standard to whatever you want, but adhere to it with 100% consistency. Otherwise you create situations where, to invoke the mandatory car analogy, the lines down the road curve to the left, while the road itself veers sharply right. Sooner or later there will be hell to pay.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    21. Re:ahhhh advertising, my good friend! by TapeCutter · · Score: 3, Interesting

      The very best that can be said about the code snippet is that it is a redundant if statement. The last time someone independently ran a static analyser on something I was working on was the Y2K thing. I sent off one MB of zipped source as requested, a month or so later I got back fifteen MB of zipped reports. It cost the company a small fortune to confirm what we had told them in the first instance - dates were all handled via a handful of functions in a single source file. The entire team of ~50 developers saw the analysis as a complete waste of time and money, the report was longer and more difficult to review than the actual code. The reason it was done is the company executives (and the law) saw it as insurance via due diligence.

      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.

      --
      And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
    22. Re:ahhhh advertising, my good friend! by Dahan · · Score: 4, 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 for years... did it not catch the problems that PVS-Studio found?

    23. Re:ahhhh advertising, my good friend! by TapeCutter · · Score: 1

      With windows or any other O/S the analyser assumes the code compiles on that O/S, I don't think cross-compiles are supported as a general rule. The only thing the analyser does not have direct access to via the source code are the #defines passed in an the command line. I have no idea why anyone would tie their analyser to visual other than to take advantage of the "app store" infrastructure.

      --
      And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
    24. Re: ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Except this bug was not found by the analysis, but by the fact, that the linker could not link.

    25. Re:ahhhh advertising, my good friend! by arglebargle_xiv · · Score: 1

      It's not even obviously $5K, in a field (source code analysis) that's notorious for high prices and opaque pricing practices, PVS is one of the worst offenders, Try finding out what it'd cost to get a long-term license for use by an open-source project of the kind they analyse and publish articles on. I mean an actual hard figure, not a wooly estimate taken from some vague terms on a web page.

    26. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      They are not the first company to offer their services to the FOSS community as loss leader for advertising. Coverty Scans did the same which was basicaly advanced Lint.

      That it works well is News for Nerds.

    27. Re: ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      "articles"

    28. Re: ahhhh advertising, my good friend! by arglebargle_xiv · · Score: 2

      cppcheck is kinda the budget version of PVS, it catches a lot of the things that PVS does, and in fact there's some cross-pollination between the two. Definitely one of the must-have tools in your dev process if you can't afford PVS.

    29. Re:ahhhh advertising, my good friend! by arglebargle_xiv · · Score: 3, Insightful

      Well that's easy enough, you just don't put the bugs in there in the first place. For example my code is mostly bug-free, I insert a small number of carefully-placed ones for Dave in Q&A to find and then we split the bug bounty between us.

    30. Re:ahhhh advertising, my good friend! by drolli · · Score: 1

      $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.

    31. Re:ahhhh advertising, my good friend! by Archtech · · Score: 1

      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.

      --
      I am sure that there are many other solipsists out there.
    32. Re:ahhhh advertising, my good friend! by Anonymous Coward · · 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.

    33. Re:ahhhh advertising, my good friend! by Andrey_Karpov · · Score: 1

      It doesn't have any prospects to make a cheap tool. I suggest looking at CppCat story, a tool we were selling for $250.

    34. Re:ahhhh advertising, my good friend! by arglebargle_xiv · · Score: 1

      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.

    35. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Would ya knock it off with the fucking LOL bullshit already!

      For Fuck Sake, you post insightful stuff all the time, then vomit out a juvenile fucking internet retardism here and there that kinda sours the experience of reading your posts.

      Thank you from internet-meme-hating people at Slashdot.

    36. Re:ahhhh advertising, my good friend! by arglebargle_xiv · · Score: 1

      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...).

    37. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Indeed it is. Another advert not even in disguise. Is this how the new owners intend to make money. Spam the news with disguised adverts more than before.

    38. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      It's a fucking advert. Plain and simple. Had it been speaking to the programmers, the designer, and how they arrived at the product, it may be different. But this is nothing more than a paid placement to sell the bloody product, fool!

    39. Re:ahhhh advertising, my good friend! by arglebargle_xiv · · Score: 1

      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.

    40. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      I would definitely want a product to flag (albeit with low priority) any instances of that sort of misleading indentation in my code,

      Why don't you simply run your code through a prettyprinter - while developing it? 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)

      The prettyprinted code won't have any indentation mistakes, because it gets indented according to syntax. You never get fooled.

    41. Re:ahhhh advertising, my good friend! by AmiMoJo · · Score: 1

      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 do a free version, or maybe partner with someone like GitHub to offer it as a (free) service.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    42. Re:ahhhh advertising, my good friend! by DrXym · · Score: 4, Insightful
      I've spent a lot of time tracking down bugs which turn out to be stupid coding errors. e.g. one recent example was a piece of code doing a strcpy on a string into a tooltip struct without limiting the length. The copy overran the struct and caused heap corruption and a crash on exit. So the bug happened in one place, the crash happened somewhere else.

      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.

    43. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Looks like the free version works by you uploading your open-source code for them to scan.
      https://scan.coverity.com/

    44. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      > Go ahead, I fucking dare you to give us a few things to be positive about. ;-)

      That line made my day :-) Thanks!

    45. Re:ahhhh advertising, my good friend! by arth1 · · Score: 1

      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.

    46. Re:ahhhh advertising, my good friend! by TheRaven64 · · Score: 1

      Coverity is free for open source projects, you can sign up from their web page and they'll scan your repo (and email out reports, or let you view them from the web interface). It's only expensive if you want to run it on your own systems or for code that isn't public.

      --
      I am TheRaven on Soylent News
    47. Re:ahhhh advertising, my good friend! by TheRaven64 · · Score: 4, 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.

      --
      I am TheRaven on Soylent News
    48. Re:ahhhh advertising, my good friend! by TheRaven64 · · Score: 1

      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 wrote something much less good as clang-format.

      --
      I am TheRaven on Soylent News
    49. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Nobody cares, jackass.

    50. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Unsafe methods like strcpy shouldn't really be used anymore. In C, you'd have access to strncpy, snprintf, etc. That being said, unless you are developing off target for an resource-constrained embedded system in VS2015, why not just use C++ style strings and avoid the issue altogether?

    51. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      You mix hard tabs and spaces for indentation? HEATHEN.

    52. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      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.

      And it has been:

      * https://svnweb.freebsd.org/base?view=revision&revision=295718

    53. Re:ahhhh advertising, my good friend! by 0100010001010011 · · Score: 1

      Only $5k? I wish I could buy development tools for my workflow for that cheap.

    54. Re:ahhhh advertising, my good friend! by avgjoe62 · · Score: 1

      This demonstrates the power of coffee.

      Coffee, making people out of assholes since the 1600's...

      --

      How come Slashdot never gets Slashdotted?

    55. Re:ahhhh advertising, my good friend! by toonces33 · · Score: 1

      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 compilers generally don't care about whitespace.

      Yeah, it is a lot of money. Really good developer tools usually are since you don't sell as many seats (Note that I haven't used this one, so I can't say whether it fits into the "really good" category). But finding these sorts of problems the "old-fashioned" way is generally a lot harder.

      Sometimes one can find these sorts of things by turning compiler warning levels up. But not all such problems can be found this way.

    56. Re:ahhhh advertising, my good friend! by TheRaven64 · · Score: 1

      No, I use tabs for indentation. I use spaces for alignment. Every line starts with n tabs, where n is the current indent level. If I need to line things up, then I will use spaces after the tabs.

      --
      I am TheRaven on Soylent News
    57. Re: ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      I remember seeing LOL in Usenet posts from the early 90s. Someone juvenile then would be in their late 30s or early 40s now.

    58. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      That's what their competitors actually do. https://scan.coverity.com/

    59. Re:ahhhh advertising, my good friend! by DrXym · · Score: 1
      Yes ordinarily I would use std:string and a bunch of useful classes from boost. But in this case it wouldn't have helped because a) I didn't write the code and if I had done I would have known to use the buffer length in the struct to control the copy and b) a std:string still has to be partially copied into a buffer so it is prone the same issue - something would have to copy the chars from the c_str() and that could trigger a problem.

      Another point is that many of the so-called "safe" methods, e.g. strncpy_s are certainly safer from the point of view that they won't do anything if the dest cannot receive the src but they're less safe from another in that the apis are more complex and to use them properly you need to check for failure and handle that. So it makes the code more complex which adds its own risk of bugs.

      Ideally stick with C++ classes but it's not possible when dealing with C APIs like Win32.

    60. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Coverity certainly does *not* work one compilation unit at a time. It builds up an entire callgraph and then does a depth-first post-order traversal. Static analyzers like Coverity get confused for one of two reasons. The first is that they are approximating an NP problem with a polynomial one. This means that sometimes a heuristic has to be used instead of an exact calculation. The other reason is because Coverity (and other good static analyzers) use an AST as part of their input and have their own compilers. If the compiler misunderstands a commonly used construct, you'll get a lot of very similar FPs. In terms of libc it has been run through tools like Coverity so many times that you're unlikely to find many real defects left unfixed. https://scan.coverity.com/proj...

    61. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      You don't need a static analyzer for code formatting issues. Just run the code through a formatter. Why look at every one? Static analysis should be used to find interprocedural defects that result from the programmer not being able to determine some behavior of the callee.

    62. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      Free via scan.coverity.com for open source projects. Coverity also has an education program where it is cheap/free but that's not well publicized.

    63. Re:ahhhh advertising, my good friend! by rthille · · Score: 1

      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...

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
    64. Re:ahhhh advertising, my good friend! by nullchar · · Score: 1

      Pretty sure they will scan open source code for free, especially if easily accessible like on github.

    65. Re:ahhhh advertising, my good friend! by nullchar · · 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.

    66. Re:ahhhh advertising, my good friend! by Anonymous Coward · · Score: 0

      If you just want some basic and free for C code, there's splint. Better than nothing at an unbeatable price.

      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.

      It says in TFA that FreeBSD already runs Coverity, but PVS-Studio found an additional 1000 bugs anyway

    67. Re:ahhhh advertising, my good friend! by arth1 · · Score: 1

      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.

    68. Re:ahhhh advertising, my good friend! by Puff_Of_Hot_Air · · Score: 1

      The safe strcpy versions crash your program by default unless you go to a bunch of effort to handle the specialised exception in a different way. The basic idea is that buffer overruns are worse then crashing, so how about we crash straight away to reveal where the bug is. There is really no reason not convert all of your strcpy's etc to strcpy_s, you'll only crash when it would otherwise be a buffer overrun.

    69. Re:ahhhh advertising, my good friend! by stoatwblr · · Score: 1

      "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.

    70. Re:ahhhh advertising, my good friend! by JohnStock · · Score: 1

      How are those TPS reports coming along? Yeahhhh.. Gonna have to ask you to come in on Saturday.. Mmmkay?

  2. Lol they lead with goto-fail by Anonymous Coward · · Score: 0

    The lead one is amazing and worth the click. It has everything I hate: curly braces on same line, curly braces left out (which is usually a direct result of having curly braces on the same line- no visual distinction), goddamned tab characters, and of course, an if statement without braces so it conditionally runs only the next expression, followed by an expression that looks (by formatting) like it is also conditional, when in fact it is unconditional.

    It's not all that good, but that's solid and made my blood boil.

    1. Re:Lol they lead with goto-fail by BitZtream · · Score: 0, Flamebait

      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
    2. Re:Lol they lead with goto-fail by Anonymous Coward · · Score: 0

      Mad much? They have pills that might help you calm down. But there probably isn't enough pills in the whole world to make you a nice person. Oh, well.

    3. Re:Lol they lead with goto-fail by Anonymous Coward · · Score: 0

      Found the guy that writes ugly, error-prone code.

    4. Re:Lol they lead with goto-fail by Anonymous Coward · · Score: 0

      > tabs are important.

      They are important to avoid.

    5. Re:Lol they lead with goto-fail by arth1 · · Score: 1

      > 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

      /* ex:ts=4
            Project default tab size: 4
      */ ... rest of code ...

      That way, copying and pasting between files that uses tabs and files that use spaces won't be much of a problem. Good editors should parse the ex modeline statements automatically, and if not, you can't say you weren't told.

    6. Re:Lol they lead with goto-fail by lgw · · Score: 1

      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.)

      --
      Socialism: a lie told by totalitarians and believed by fools.
    7. Re:Lol they lead with goto-fail by Viol8 · · Score: 2

      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.

    8. Re:Lol they lead with goto-fail by lgw · · Score: 1

      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).

      --
      Socialism: a lie told by totalitarians and believed by fools.
  3. "their" company by Anonymous Coward · · Score: 0

    Andrey_Karpov sure likes "their" company which he's totally not affiliated with.

    I'm as happy as anyone about the higher frequency of technical content being posted recently, but not stuff like this. It smelled self-serving as soon as "this is one of the most acceptable and useful ways of promoting a proprietary application".

    1. Re:"their" company by BitZtream · · Score: 0

      Uhm, he works for them, of course his biased, and he has astroturfed for them all along.

      https://mvp.microsoft.com/en-u...

      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 of things.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re: "their" company by Anonymous Coward · · Score: 0

      Andrey Karpov the child abuser? I read he was working as a programmer but did not know he posts on Slashdot.

    3. Re: "their" company by Andrey_Karpov · · Score: 1

      I am busy doing many things. I am one of the founders of PVS-Studio. Besides that, I also publish the news and communicate with the audience. I suppose, it's a nice thing that you can discuss technical moments with me.

    4. Re: "their" company by Anonymous Coward · · Score: 0

      So you are a child abuser? Nice to know. You seemed to gloss over that statement and completely ignore. So I take that as you are a child abuser. Make sure you register yourself or the law will come knocking.

  4. Another one? by 110010001000 · · Score: 0

    How many static code analyzers do we need? It must be really boring in Russia.

    1. Re:Another one? by Anonymous Coward · · Score: 0

      I don't know, but I'm dying for the report from running against the Windows 10 code.

    2. Re:Another one? by Andrey_Karpov · · Score: 1

      Static analysis development is an opportunity for us to achieve some success in life. It isn't very interesing just to do outsource work, as we want something more. It feels that we are getting there. :)

    3. Re:Another one? by Andrey_Karpov · · 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:

      Here are the checks of C# projetcs:

    4. Re:Another one? by Anonymous Coward · · Score: 0

      Well, it's not very likely that we'll be given a chance to run the analysis on Windows.

      THAT'S THE JOKE.

    5. Re:Another one? by 110010001000 · · Score: 1

      There are lots of other projects to work on that will give you more success than static code analyzers. The market is saturated with those, and many of them are free.

  5. Have they checked systemd? by Anonymous Coward · · Score: 0

    Have they checked systemd? What were their findings if they have?

    1. Re:Have they checked systemd? by Anonymous Coward · · Score: 0

      Spell it like SystemD. That way it looks like a dick. Like one that's fucking you in the ass in doggy style.

    2. Re:Have they checked systemd? by Megol · · Score: 1

      This isn't the correct forum to publish your perverse sexual fantasies.

    3. Re:Have they checked systemd? by Rockoon · · Score: 1

      I for one would like to hear more of the things that he wishes systemd would do to him.

      --
      "His name was James Damore."
    4. Re:Have they checked systemd? by Anonymous Coward · · Score: 0

      Every thread. Every fucking thread. Some twat whining about systemd. Just fuck off and die.

    5. Re:Have they checked systemd? by bytesex · · Score: 1

      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?

      --
      Religion is what happens when nature strikes and groupthink goes wrong.
    6. Re:Have they checked systemd? by Megol · · Score: 1

      Now you made me feel sick :(

  6. Poor Practices by PVS Studio and HexRays by ilikenwf · · Score: 3, Interesting

    It seems like every time they do this for promotion they just claim everything as a "bug" without really individually investigating and reporting all of them, taking only some obviously wrong ones and then lumping the whole report onto the project's bug tracker, if we're lucky.

    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.

    1. Re:Poor Practices by PVS Studio and HexRays by ThorGod · · Score: 1

      It's pretty clearly just a marketing strategy if they're not giving teams access to their tools and their reports.

      --
      PS: I don't reply to ACs.
    2. Re:Poor Practices by PVS Studio and HexRays by ilikenwf · · Score: 1

      Yeah, which sucks. People would be more interested if they'd at least provide the xml exports from their tools.

      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."

    3. Re:Poor Practices by PVS Studio and HexRays by BitZtream · · Score: 0, Troll

      t seems like every time they do this for promotion they just claim everything as a "bug" without really individually investigating and reporting all of them, taking only some obviously wrong ones and then lumping the whole report onto the project's bug tracker, if we're lucky.

      Yep, I've looked at the article and found a couple legitimate bugs, and the rest of it is the authors complete misunderstanding of what he's talking about. He doesn't seem to understand that strcpy and memcpy DO NOT DO THE SAME THING. He assumes that an extra tab means an if was done incorrectly, goes on about bad practices when its just that he doesn't know what the code is doing and taking 3 seconds to understand that a MACRO behaves differently on different architectures and maybe, just maybe, the hardcode 0 makes sense on that specific architecture and not on others ... which he could have found had he simply checked the places where the MACRO was defined instead of just the one that was compiled.

      This guy is just using this for slashvertisments, which is great, because we can now pick apart his shitty analysis and make fun of it :)

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    4. Re:Poor Practices by PVS Studio and HexRays by Anonymous Coward · · Score: 0

      At least there are keygens and stuff out for the analyzer. If I were a legit business I'd pay for it but otherwise screw these guys.

    5. Re:Poor Practices by PVS Studio and HexRays by Anonymous Coward · · Score: 0

      People would be more interested if they'd at least provide the xml exports from their tools.

      Towards the end of that article, they say this:
      "Nevertheless, the development team of FreeBSD got the full list of the analyzer warnings that should be examined"

    6. Re:Poor Practices by PVS Studio and HexRays by Anonymous Coward · · Score: 0

      It starts with the "github master branch" being nothing more than a courtesy copy of the actual repository, which is still under subversion management.

      Not that I think svn is any better, but for better or for worse that is what the FreeBSD project settled on years ago as successor of CVS. Though even their own "developers" these days frankly understand little of the intricacies of managing a large FOSS project and the wisdom of hosting your code or anything really on github. FreeBSD had a couple strong points over linux, but these days it only has them because it hasn't thrown them away yet; new ones it gets because linux does stupid stuff, not because they do smart stuff. A pity, really. Even so, this company should perhaps have known better than to be mentally lazy and go to github. For several reasons, really; listing them left as an exercise.

    7. Re:Poor Practices by PVS Studio and HexRays by Andrey_Karpov · · Score: 1

      Perhaps, I didn't get you quite right. Could it be that you didn't read the article attentively enough? The things we write about aren't really nonsense. For example, we are aware what is strcpy and memcpy. At times we see that people read our article not very thoroughly and then start arguing. I'll provide such an example concerning memcpy - see Fragment N1 and the comments below. This is a completely different case, I've provided it to show that the readers should carefully look though the code examples we provide.

    8. Re:Poor Practices by PVS Studio and HexRays by Anonymous Coward · · Score: 0

      If you're open source uses a qualifying license, Coverity will let you use their product for free. scan.coverity.com check it out.

    9. Re:Poor Practices by PVS Studio and HexRays by tlhIngan · · Score: 1

      Yep, I've looked at the article and found a couple legitimate bugs, and the rest of it is the authors complete misunderstanding of what he's talking about. He doesn't seem to understand that strcpy and memcpy DO NOT DO THE SAME THING. He assumes that an extra tab means an if was done incorrectly, goes on about bad practices when its just that he doesn't know what the code is doing and taking 3 seconds to understand that a MACRO behaves differently on different architectures and maybe, just maybe, the hardcode 0 makes sense on that specific architecture and not on others ... which he could have found had he simply checked the places where the MACRO was defined instead of just the one that was compiled.

      Or perhaps the trickiest bugs are caused by the most subtle of errors?

      I mean, the concerns raise issues with what's happening in the code.

      The tab issue - the code LOOKS like it does one thing, but it does something else completely. Depending on where it is in the code it could be on the scale of the "goto fail" bug (which was the result of the same kind of error) or it just leads to an obscure crash if certain conditions are right.

      And when blocks of code in an if-then-else statement start being identical, that usually mean something is messed up. Or when you compare something against itself.

      A lot of bugs are subtle ones - they don't fail immediately, but perhaps after a little while things start going wonky because the condition is being tripped. Or perhaps it's a security issue.

      Perhaps it's being pedantic, but it looks like it catches what could be issues that would take weeks to debug.

      And sometimes stuff is hidden through macros so it looks innocent, but because of the way the macro is written, it comes out completely different. Not parenthesizing macros leads to all sorts of strange bugs since the C preprocessor just works on blocks of and not semantics. So a macro that looks like a function doesn't necessarily behave like one (e.g., any math done in a macro is passed verbatim to the macro and not evaluated.

      I'd say the bugs found are not the typical crash bugs or reproducible ones you fine, but more along the lines of those that happen infrequently and result in crashes that no one can really determine the cause because the code paths are executed frequently.

  7. Kernel devs suck at code style by Anonymous Coward · · Score: 0

    We would fire anyone who wrote code in the way kernel devs write code. Minimal comments, shitty variable names, shitty function names, ternary shit all over the place... Ugh. No wonder there are bugs.

    1. Re:Kernel devs suck at code style by Anonymous Coward · · Score: 0

      If you bothered to read the article you'd see that the analysis was conducted on preprocessed files - so all of the original comments have been stripped out by the preprocessor.

  8. How the fuck are you so sure, paco? by Anonymous Coward · · Score: 0, Flamebait

    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.

    1. Re:How the fuck are you so sure, paco? by TheRaven64 · · Score: 1

      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.

      --
      I am TheRaven on Soylent News
  9. This ought to fix most of that ... :-) by fahrbot-bot · · Score: 3, Funny

    PVS-Studio detected more than 1000 suspicious code fragments that are most likely bugs or inaccurate code.

    /*NOTREACHED*/

    --
    It must have been something you assimilated. . . .
  10. Those aren't bugs; that's untested code. by holophrastic · · Score: 0, 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 I wind up producing -- which are all interactive bugs across features.

    Of course, I ain't in C.

  11. Closed Source Saves The Day Again by Anonymous Coward · · Score: 0

    Glad to see the commercial world saving you guys again.

  12. The tab thing by Anonymous Coward · · 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 introduced by well meaning code cleanups!

    1. Re:The tab thing by arth1 · · 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.

      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 indented. That's your fault.use editors in a different OS that your code doesn't support in the first place.

      Granted, it is better to always transform tabs into spaces, but it's by no means required to cater to those who don't follow the standards you have set. Especially not if they're using a proprietary editor on an OS you don't even support.

    2. Re:The tab thing by ChunderDownunder · · Score: 1

      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 function.

      e.g. one of the first functions Theo and the libressl team did when creating the heart-bleed inspired fork was to reformat every source file according to OpenBSD guidelines.

      That might sound like a team-lead has OCD and open a holy-war on tabs vs spaces but at the end of the day you accept the rules of the guys that are paying you... (Dunno how that's enforced on volunteer projects, mind you!)

    3. Re:The tab thing by Anonymous Coward · · Score: 0

      I don't mind using tabs for indentation, OR spaces, but never a mix of the two.

      Anyone who does that goes on my shit list.

    4. Re:The tab thing by Anonymous Coward · · Score: 0

      >This is perfectly fine: /* ex:ts=4
      */
      >[4 spaces]if (something is there)
      [>8 spaces]tab1 dinit the something
      >[tab]tab2 close the something

      Tabs are supposed to be for indentation, spaces for alignment.

      https://www.emacswiki.org/emacs/SmartTabs

      It's 2016, can we please stop doing that stupid interchangeable usage of tabs and spaces? There's a *reason* they are different characters.

      >It will display with the first and third lines aligned, and the second line indented.

      By accident.

      >Granted, it is better to always transform tabs into spaces,

      No.

    5. Re:The tab thing by fnj · · 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.

      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 C programmer of unacceptable quality.

    6. Re:The tab thing by Anonymous Coward · · 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?"

    7. Re:The tab thing by metaforest · · Score: 1

      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 flag either example as a style error. The reason is that the intent of the programmer is ambiguous. The reason it is ambiguous is that a botched copy-paste action, or a bad patch can cause formatting errors like this and then the intended meaning is in doubt.

      if (condition) {
                  statement1;
      }
      statement2;

      or

      if (condition) statement1;
      statement2;

      Is not going to get flagged, as all of the elements are stylistically coherent. Though, IMO, the second form is not good style, it is still clear what was intended.

  13. Jesus Christ by Anonymous Coward · · Score: 0

    That's a job for J.C. and the Pussy Cats. While kids are jailed on those Pewdeepie videos (not googling the name of this idiot, because names like that are intended to be googled) instead of watching IDK... CrashCourse. The fault is on the lack of stars on the sky. Bats use stars to navigate, then how they will know where are places they had been before, where the good mosquitoEs are? How can I get an army of NERDS (level needed to fix OS bugs - Level 1 is Pascal/BASIC noobs, level 2 are C ninjas, and level NERDS is *&$WSXCVGBYHU(O)POKML*&ITR%$#TQ@Awzxcdf*&t*(y(upjiik&tu, about programing, got it?). I need go to Russia. God... They have a day just for the coders... (probably they kill a random developer as a celebration, IDK). Ah, to find out a good knight of the round, just look if it has the eyes of a tired person, with a smile of an winner.

  14. Its size of code and users not dev team ... by perpenso · · Score: 1

    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.

    1. Re: Its size of code and users not dev team ... by Entrope · · Score: 1

      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.

  15. Two character comments are good ... by perpenso · · Score: 2

    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.

    1. Re:Two character comments are good ... by Rockoon · · Score: 1

      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 are pulling from a grab bag of clever tricks in the name of optimization. It is these variable comments combined with the code (aka intent) that allows the programmer to see the logic of it all, and you better see the logic of it all if you intend to maintain the code.

      --
      "His name was James Damore."
    2. Re:Two character comments are good ... by AmiMoJo · · Score: 1

      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?

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:Two character comments are good ... by TheRaven64 · · Score: 4, Interesting

      This is one of my pet peeves too. It's also something that I really like about Smalltalk: there is no operator precedence, operators are evaluated left to right and if you want something other than left-to-right order, then you must add parentheses. This means that you never spend time in Smalltalk code wondering if the developer got the precedence wrong.

      --
      I am TheRaven on Soylent News
    4. Re:Two character comments are good ... by Anonymous Coward · · Score: 0

      Sadly most people learn operator precedence in math with +-/* and that would once again lead to bugs until they manage to unlearn it.

    5. Re:Two character comments are good ... by perpenso · · Score: 1

      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".

  16. why not glibc? by Anonymous Coward · · Score: 0

    Maybe they should have gone where the smoke is and ran glibc through this.

  17. This is getting to be quite a crowded space... by Anonymous Coward · · Score: 0

    There are quite a number of tools in this space: Coverity (pay-ware unless you qualify), lint, splint or my personal favorite on Windows: Cppcheck

    1. Re:This is getting to be quite a crowded space... by Anonymous Coward · · Score: 0

      The mentioned in TFA that FreeBSD already uses Coverity. So they've only found things that Coverity missed.

    2. Re:This is getting to be quite a crowded space... by arth1 · · Score: 1

      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.

  18. Bethesda Softworks by Merovign · · Score: 5, Funny

    Somebody get this to Bethesda, stat!

  19. BitZtream was wrong. They just fixed it. by Anonymous Coward · · Score: 4, Interesting

    BitZtream was wrong. A fix has been committed which adds the missing parenthesis.

    1. Re:BitZtream was wrong. They just fixed it. by Anonymous Coward · · Score: 0

      Fucking hell. This kind of "goto fail" crap is why I try to be strict with putting braces around all if and else clauses. At least they're using 1TBS, which only adds one line when you add the braces, and also reduces the chance of opening braces falling victim to merge drift.

  20. I have four words for FreeBSD... by Anonymous Coward · · Score: 0

    Developers! Developers! Developers! Developers!
    https://www.youtube.com/watch?v=rRm0NDo1CiY

  21. Re:Slashdot is dying by Anonymous Coward · · Score: 0

    Aw, c'mon moderators. I posted this as a parody of the infamous *BSD is dying troll to be funny. Have a sense of humor, please.

  22. he's way overconfident by epine · · Score: 1

    A big code fragment was copied, but later no changes were made.

    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).

    1. Re:he's way overconfident by ledow · · Score: 2

      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.

  23. Re:Slashdot is dying by Anonymous Coward · · Score: 0

    You didn't use the joke tags

  24. Java support by Anonymous Coward · · Score: 0

    Is there a similar tool for java? so that I can check my project.

    1. Re: Java support by Anonymous Coward · · Score: 0

      Findbugs and checkstyle are Java equivalents

  25. Focus on your own site first. by Anonymous Coward · · Score: 0

    You would think that with all their bug hunting, they would actually bother to fix the english on their site. I know it's a pro tool, but jesus fucking christ I'm not going to recommend to anyone a site that seems like it is the output of google fucking translate.

  26. No you miss the point by Anonymous Coward · · Score: 0

    It isn't the tabs, its that it appears from the code to be

    if (something)
    {
      deinitialize the something
      close the something
    }

    He talks about the tabs indicating perhaps the guy missed the brackets, but its not a style guide thing it looks like an actual bug.

  27. Your devs work cheap? by Anonymous Coward · · Score: 0

    you're looking at spending about $5k for the product, unless you are a large development team, cost benefit ratio is low

    Geez, your developers must work really cheap. $5K is a few days of work for one dev. Including overhead, $200/hr or $2,000/day are good seat-of-the-pants numbers to use for the cost of a developer.

    If this tool finds two bugs in your code base it pays for itself.

    Would you pay someone to build your house if the only tools they used were a small hand saw and a 12-oz hammer? Or would you rather pay a professional who uses modern power tools that make the construction more COST EFFICIENT?

  28. Oh, Karpov, you inveterate spammer... by psychonaut · · Score: 1, Informative

    The submitter, Andrey Karpov, is one of the developers of PVS-Studio. The article he's plugging was written by yet another PVS-Studio developer. I wouldn't be in the least surprised if this got voted to the front page by an army of PVS-Studio sockpuppets. They've been doing the same thing on Wikipedia for years (though their site was long ago put on a Wikimedia-wide spam blacklist), and also post similar spamvertisements, masquerading as "bug reports", to the issue trackers of prominent free software projects such as Mozilla.

    1. Re:Oh, Karpov, you inveterate spammer... by Andrey_Karpov · · 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 to know that there is a super useful article StdAfx.h. Burn it all! :)

    2. Re:Oh, Karpov, you inveterate spammer... by psychonaut · · Score: 1

      I had nothing to do with your websites getting blacklisted from Wikipedia. The administrators in the anti-spam brigade did that back in 2008.

    3. Re:Oh, Karpov, you inveterate spammer... by shutdown+-p+now · · Score: 1

      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.

  29. Aren't these checks in the newest GCC? by Anonymous Coward · · Score: 0

    Things like comparisons of two equal values, and confusing indentation errors? Hmm...

  30. Dear PVD Team: by buddyglass · · Score: 1

    Please do linux, glibc, openssl, MariaDB, PostgreSQL, httpd, nginx, Chrome, Firefox, python, ruby and gcc next. Thanks.

    1. Re:Dear PVD Team: by Andrey_Karpov · · Score: 2

      See "An always up-to-date list of articles describing errors that we find in open source projects with PVS-Studio analyzer".

      We have checked this projects from the list you've provided:

    2. Re:Dear PVD Team: by Anonymous Coward · · Score: 0

      Oh cool, you did Firebird in 2014.

      Why do the Russians love that SQL DB so much?

    3. Re:Dear PVD Team: by Andrey_Karpov · · Score: 1

      I really don't know. We just got several requests to check this project. The more people ask us to check something, the higher the chance that we'll do it. :)

    4. Re:Dear PVD Team: by buddyglass · · Score: 1

      Awesome! Thanks for there response, and for the positive effect you're having. Fewer bugs makes me happy.

  31. Re:Slashdot is dying by Anonymous Coward · · Score: 0

    You obviously didn't read the videos poll thread. 90% (that cared to respond) of /. doesn't want videos.

  32. Special by Anonymous Coward · · Score: 0

    This isn't 1980, we can parse identifier names that are longer than 2-3 characters.

    mfp, ia, ifa, osti, mp, ha, ccb, cpi, hba, sbp, qla_tx_tso

    Holy hell, people, I think we can stand to be slightly more verbose. I hate diving into code like this.

    1. Re:Special by kmoser · · 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?

  33. Re:Slashdot is dying by Anonymous Coward · · Score: 0

    Aww fuck, thanks to moderation hiding the original post, I saw the replies as linked below the youtube post above it. And it's not "moderators", because it only takes a single mod to go from 0 to -1.

  34. The "recurring check" warning isn't by scdeimos · · Score: 1

    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.: Slashdot's comment editor sucks ass.

  35. heap corruption debugging ftw by Anonymous Coward · · Score: 0

    Sounds familiar. Application Verifier + Gflags + WinDbg (all available for free in Windows SDKs) saved me many a time here.