4 ms·

It is easier to find a bug then to select token that is "correct". Also some of those bugs are detected even by GCC.

by ucho 10y ago

unwind 10y ago
So why are they still "live" in the originating projects, then? Honest question. Perhaps nobody reads their compiler warnings?
- fao_ 10y ago
  I wouldn't be surprised. The amount of compile warnings I've seen when building things from source are, quite frankly, astounding
  - CorpOverreach 10y ago
    I've gotten used to seeing walls of warnings/messages when compiling things from source. It's almost a case of boy-who-cried-wolf at this point. You get lots of warnings, but it works! And they're not always due to the programmer being negligent. I've had many cases where something compiles cleanly on one box, but throws warnings on another because of a slightly different version of a compiler or library. When I compile something and it runs through the entire process with not a single warning, it's truly a "...whoa" moment.
    - ryandrake 10y ago
      Wow. When I worked as a developer, one thing I would always insist on (or push for when I was not senior enough to insist on things) was -Wall and -Werror. If your code has a warning, there is a reason for it and you should address it. Sometimes the warning is benign, so you address it with a thoughtful comment to the effect of "silence X warning - it's not a factor because Y". But at least address them! Reasons to be so anal on warnings: 1. Broken windows theory. A code base full of warnings signals that nobody cares about anything. People will get better about finding and caring about the big things when they are forced to also care about the little things. 2. When your project has a "wall of warnings" there are real bugs hiding in there. I guarantee it and would bet money on it. Here's your opportunity to fix them and you don't even need QA to point them out. Your compiler is literally telling you. 3. When things compile on one box but not another, that's a big red flag that you have something platform-specific or library version-specific that WILL bite you some time later. unsigned-signed and sizeof(int) mismatches are good examples of this. The whole "it compiles and works therefore it's done" mentality is some serious "second-year programming class" level shit, but it's everywhere. Good projects, where people care and have disciplined attitudes, discourage it.
      - fao_ 10y ago
        I would probably add `-std=<lowest compatible version> -pedantic-errors` to that as well. Aside from that I agree totally.
      - dmm 10y ago
        Adding -Werror to your build system sucks because future compilers implement new warnings making it very difficult to recreate new builds with new compilers, for instance when bisecting a bug. Add it to your local build with "./configure CFLAGS=-Werror" or similar? That's great!
        nomel 10y ago
        Oh, that's interesting. What would be the method for handling this? Branch a known good commit, fix the warning, rebase everything from the future, then bisect?
        astrange 10y ago
        Also, no team below you can ever use -Wdeprecated, and no compiler team can ever test your project with a new compiler, because all of it will break your build.
        doubleplaid 10y ago
        Deprecation annotations are incredibly helpful, many thanks. This is off the top of my head and likely clang specific: -Werror // Treat all warnings as errors -Wno-error=deprecated // Except deprecated warnings -Wno-error=deprecated-implementation // And these ones too The deprecated-implementation warning flag should likely be made part of the deprecated warning group, but it's not yet. See the clang source for a helpful TODO? comment. -Wclang-please-warn-about-warning-groups-that-are-missing-warnings ?
      - doubleplaid 10y ago
        Consider adding -Wextra. It adds a lot of warnings that will likely be bugs, but may throw more false positives than -Wall. If you are willing to put up with more false positives and/or are willing to disable certain warnings, consider -Weverything.
  - svens_ 10y ago
    Yeah. Unfortunately this is very true and relevant. Many projects have a huge number of warnings - not all of them are errors, which makes it hard to spot new non-obvious bugs when they are made. This "game" only tells half the story about static code analysis. Sure it's very impressive that all those bugs have been found and they are indeed hard to spot. However what's actually important would be the percentage of false-positives.
- jackmott 10y ago
  Many people use other than GCC
  - AndreyKarpov 10y ago
    But: PVS-Studio Probes into Linux' Innards - http://www.viva64.com/en/b/0299/ http://www.viva64.com/en/b/0299/
iheartmemcache 10y ago
I'd bet a weeks salary (seriously) that Coverity (yeah yeah it's expensive, whatever) will catch > 90% of these with maybe a 10% false positive, and Code Analysis in VS would hover around the 80% mark with maybe a 15% false positive (both for C++; for ANSI C, move that up to 95% and 90% accordingly). ccc-analyzer/c++-analyzer for clang/llvm would probably hit the 90-ish mark for ANSI C too.
- AndreyKarpov 10y ago
  You are optimist. If compilers were good, there would be the base of these errors: http://www.viva64.com/en/examples/ http://www.viva64.com/en/examples/ And Coverity is not perfect: http://www.viva64.com/en/b/0408/#ID0EGMAC http://www.viva64.com/en/b/0408/#ID0EGMAC

It is easier to find a bug then to select token that is "correct". Also some of those bugs are detected even by GCC.

by ucho 10y ago

It is easier to find a bug then to select token that is "correct". Also some of those bugs are detected even by GCC.

So why are they still "live" in the originating projects, then? Honest question. Perhaps nobody reads their compiler warnings?

fao_ 10y ago
I wouldn't be surprised. The amount of compile warnings I've seen when building things from source are, quite frankly, astounding
- CorpOverreach 10y ago
  I've gotten used to seeing walls of warnings/messages when compiling things from source. It's almost a case of boy-who-cried-wolf at this point. You get lots of warnings, but it works! And they're not always due to the programmer being negligent. I've had many cases where something compiles cleanly on one box, but throws warnings on another because of a slightly different version of a compiler or library. When I compile something and it runs through the entire process with not a single warning, it's truly a "...whoa" moment.
  - ryandrake 10y ago
    Wow. When I worked as a developer, one thing I would always insist on (or push for when I was not senior enough to insist on things) was -Wall and -Werror. If your code has a warning, there is a reason for it and you should address it. Sometimes the warning is benign, so you address it with a thoughtful comment to the effect of "silence X warning - it's not a factor because Y". But at least address them! Reasons to be so anal on warnings: 1. Broken windows theory. A code base full of warnings signals that nobody cares about anything. People will get better about finding and caring about the big things when they are forced to also care about the little things. 2. When your project has a "wall of warnings" there are real bugs hiding in there. I guarantee it and would bet money on it. Here's your opportunity to fix them and you don't even need QA to point them out. Your compiler is literally telling you. 3. When things compile on one box but not another, that's a big red flag that you have something platform-specific or library version-specific that WILL bite you some time later. unsigned-signed and sizeof(int) mismatches are good examples of this. The whole "it compiles and works therefore it's done" mentality is some serious "second-year programming class" level shit, but it's everywhere. Good projects, where people care and have disciplined attitudes, discourage it.
    - fao_ 10y ago
      I would probably add `-std=<lowest compatible version> -pedantic-errors` to that as well. Aside from that I agree totally.
    - dmm 10y ago
      Adding -Werror to your build system sucks because future compilers implement new warnings making it very difficult to recreate new builds with new compilers, for instance when bisecting a bug. Add it to your local build with "./configure CFLAGS=-Werror" or similar? That's great!
      - nomel 10y ago
        Oh, that's interesting. What would be the method for handling this? Branch a known good commit, fix the warning, rebase everything from the future, then bisect?
      - astrange 10y ago
        Also, no team below you can ever use -Wdeprecated, and no compiler team can ever test your project with a new compiler, because all of it will break your build.
        doubleplaid 10y ago
        Deprecation annotations are incredibly helpful, many thanks. This is off the top of my head and likely clang specific: -Werror // Treat all warnings as errors -Wno-error=deprecated // Except deprecated warnings -Wno-error=deprecated-implementation // And these ones too The deprecated-implementation warning flag should likely be made part of the deprecated warning group, but it's not yet. See the clang source for a helpful TODO? comment. -Wclang-please-warn-about-warning-groups-that-are-missing-warnings ?
    - doubleplaid 10y ago
      Consider adding -Wextra. It adds a lot of warnings that will likely be bugs, but may throw more false positives than -Wall. If you are willing to put up with more false positives and/or are willing to disable certain warnings, consider -Weverything.
- svens_ 10y ago
  Yeah. Unfortunately this is very true and relevant. Many projects have a huge number of warnings - not all of them are errors, which makes it hard to spot new non-obvious bugs when they are made. This "game" only tells half the story about static code analysis. Sure it's very impressive that all those bugs have been found and they are indeed hard to spot. However what's actually important would be the percentage of false-positives.
jackmott 10y ago
Many people use other than GCC
- AndreyKarpov 10y ago
  But: PVS-Studio Probes into Linux' Innards - http://www.viva64.com/en/b/0299/ http://www.viva64.com/en/b/0299/

iheartmemcache 10y ago

I'd bet a weeks salary (seriously) that Coverity (yeah yeah it's expensive, whatever) will catch > 90% of these with maybe a 10% false positive, and Code Analysis in VS would hover around the 80% mark with maybe a 15% false positive (both for C++; for ANSI C, move that up to 95% and 90% accordingly). ccc-analyzer/c++-analyzer for clang/llvm would probably hit the 90-ish mark for ANSI C too.

AndreyKarpov 10y ago
You are optimist. If compilers were good, there would be the base of these errors: http://www.viva64.com/en/examples/ http://www.viva64.com/en/examples/ And Coverity is not perfect: http://www.viva64.com/en/b/0408/#ID0EGMAC http://www.viva64.com/en/b/0408/#ID0EGMAC