5 ms·

And both have existing tools to find those bugs that people often just don't use.

pjmlp 3y ago
Since 1979 with the invention of lint by Stephen Johnson at Bell Labs. https://en.wikipedia.org/wiki/Lint_(software) https://en.wikipedia.org/wiki/Lint_(software)
- UncleMeat 3y ago
  Static analysis as a bugfinding tool has proven to be insufficient, especially for large C++ binaries and JS programs. Both languages are nightmares for precise and scalable analysis. Coverity exists. They've got a great product. But it doesn't solve the problem.
  - pjmlp 3y ago
    It doesn't solve everything, it solves even less when it isn't used.
    - UncleMeat 3y ago
      Of course. But these issues will remain near the top of the list indefinitely if people just leverage traditional analysis tools. I love static analysis. I did my PhD in it. But we'll still be talking about use after free in 2073 if we just try to chase higher K in our analysis implementations.
      - pjmlp 3y ago
        Naturally static analysis alone doesn't fix use after free in all possible cases, however it already does fix several of them when the analyser can see everything on the existing source code. The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time. Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.
        UncleMeat 3y ago
        Having spent well over a decade in this space, I assure you that the root cause of limitations for static analyzers doing lifetime analysis in C++ is not separate compilation or partial program analysis caused by shared libraries.
        pjmlp 3y ago
        Naturally it isn't. Again, even if not perfect, and doesn't cover all use cases, what about people would actually use something at all? During that decade, how much time did you spent looking at the human side of the problem instead of what the tools can achive?
        UncleMeat 3y ago
        Nowhere did I suggest that we shouldn’t use these tools or spend time improving them. UX for tools more powerful than local AST matching indeed tends to be quite bad because explaining the chain of reasoning for an alarm is difficult. My only point is that without a different approach we will continue to have the same problems in 2073.

Since 1979 with the invention of lint by Stephen Johnson at Bell Labs. https://en.wikipedia.org/wiki/Lint_(software) https://en.wikipedia.org/wiki/Lint_(software)

UncleMeat 3y ago
Static analysis as a bugfinding tool has proven to be insufficient, especially for large C++ binaries and JS programs. Both languages are nightmares for precise and scalable analysis. Coverity exists. They've got a great product. But it doesn't solve the problem.
- pjmlp 3y ago
  It doesn't solve everything, it solves even less when it isn't used.
  - UncleMeat 3y ago
    Of course. But these issues will remain near the top of the list indefinitely if people just leverage traditional analysis tools. I love static analysis. I did my PhD in it. But we'll still be talking about use after free in 2073 if we just try to chase higher K in our analysis implementations.
    - pjmlp 3y ago
      Naturally static analysis alone doesn't fix use after free in all possible cases, however it already does fix several of them when the analyser can see everything on the existing source code. The main issue is the community sub-culture of not adopting tooling as it isn't perfect 100% of the time. Many of the C++ security conscious folks end up being polyglot, as this subculture eventually wears one out.
      - UncleMeat 3y ago
        Having spent well over a decade in this space, I assure you that the root cause of limitations for static analyzers doing lifetime analysis in C++ is not separate compilation or partial program analysis caused by shared libraries.
        pjmlp 3y ago
        Naturally it isn't. Again, even if not perfect, and doesn't cover all use cases, what about people would actually use something at all? During that decade, how much time did you spent looking at the human side of the problem instead of what the tools can achive?
        UncleMeat 3y ago
        Nowhere did I suggest that we shouldn’t use these tools or spend time improving them. UX for tools more powerful than local AST matching indeed tends to be quite bad because explaining the chain of reasoning for an alarm is difficult. My only point is that without a different approach we will continue to have the same problems in 2073.