3 ms·
I'm pretty sure everyone uses a basic static analyzer for code completion, formatting, and syntax. Most IDEs just set it up for you. I've used the "professiona
by aeonik 3y ago
I'm pretty sure everyone uses a basic static analyzer for code completion, formatting, and syntax. Most IDEs just set it up for you.
I've used the "professional" security ones including TrustInSoft and Synopsis tools. They are pretty cool, but give a lot of false positives, you either need teams to really understand the security model of these systems, or to have a dedicated team manage and triage things.
They do a great job catching some egregious mistakes though.
That being said, I think Rust is takes the better approach of trying to build safety directly into the language and compiler. Though I think there is still a lot of room for innovation here.
- Alifatisk 3y ago> I'm pretty sure everyone uses a basic static analyzer for code completion, formatting, and syntax. Most IDEs just set it up for you. Yeah, this extension is almost the default choice for vscode https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools https://marketplace.visualstudio.com/items?itemName=ms-vscod...
- flohofwoe 3y agoAs far as I'm aware the vanilla Intellisense (e.g. error squiggles and warnings while typing) isn't doing proper static analysis only simple syntax error checks. And while clang-tidy is integrated with the MS C++ extension, it needs to be run manually, or automatically on file save/open (see: https://devblogs.microsoft.com/cppblog/visual-studio-code-c-december-2021-update-clang-tidy/ https://devblogs.microsoft.com/cppblog/visual-studio-code-c-...) - I guess it's too expensive to just run in the background while typing.
- pjmlp 3y agoNowadays that isn't any longer the case, linting is also performed, at least on Visual Studio proper. https://learn.microsoft.com/en-us/cpp/ide/cpp-linter-overview?view=msvc-170 https://learn.microsoft.com/en-us/cpp/ide/cpp-linter-overvie...
- flohofwoe 3y ago> ...code completion, formatting, and syntax... These are usually linters, not proper static analyzers (although the popular clang-tidy is a bit of both). A "proper" static analyzer follows control flow and tries to cover all possible variations (and then reporting things like "this pointer here will be null when this other function 10 levels up the callstack is called with parameter "x" having the value "N" - Xcode even gives you a control-flow visualization overlayed as arrows over the source code to give a better idea how the static analyzer arrived at that conclusion). Running code through a static analyzer takes many times longer than compiling the code. > They are pretty cool, but give a lot of false positives. Analyzers usually take assert() as hints (e.g. 'assert(ptr)' hints to the analyzer that ptr isn't expected to be null - so you won't get a "this pointer can potentially be null" false positive. The tighter your assert checks, the fewer false-positives you'll get.
- aeonik 3y agoIn my brain "linters" ⊆ "static analyzers". Anything that looks at code without running it qualifies. I don't know what you mean by "proper" static analyzer. The static analyzer libraries that I use do produce lint, but this is among many other useful insights.