SoylentNews is people
SoylentNews
O'Reilly and Software Improvement Group conducted a survey about secure coding: https://www.oreilly.com/ideas/the-alarming-state-of-secure-coding-neglect
Much of it is as expected but I stumbled upon this tidbit:
"[Static analysis] was reported as being used by 25% of respondents. One-third of those who didn't use it said it was too expensive. The rest of the non-users were fairly evenly divided among other explanations: tools were not available for their technology, were too hard to use, had too many false positives, or were not usable in Agile development."
When developing I have almost always used compiler warnings (gcc/acc/icc/cxx/clang) and dedicated tools cppcheck/flexelint/coverity-scan/pvs-studio/clang-analyze so the above snippet depressed me because catching errors sooner rather than later makes them much cheaper to fix. Static analysis tools can require much configuration, can be expensive, and be time-consuming, and I guess that for some languages such tools don't even exist. The part about static analysis tools not fitting a development process struck me as downright odd.
What is your take on this? Why aren't you using static analysis (and if you do: which one and for what?)
(Score: 0) by Anonymous Coward on Wednesday May 10 2017, @04:38AM (11 children)
I compile my code with -Wall. Does that count?
by the way, I went to the famous article, and "static analysis" is not defined.
(Score: 2) by The Mighty Buzzard on Wednesday May 10 2017, @05:09AM
Yup, rehash (the fork formerly known as slashcode) here runs with use strict and use warnings except in a very, very few places where we do something funky but legitimate. That's about all you can ask for this codebase though. I think a proper static analysis tool would straight up shit out its nostrils when presented with some of the stuff we inherited.
As for Rust, I haven't really found a static analysis tool yet but I leave all the warnings turned on except for the ones about snake case because my Rust skills aren't shiny enough to make me think I know what I'm doing better than the compiler yet.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday May 10 2017, @05:21AM (8 children)
It's a good start. Look into -Wextra - it may be too much for you, and it gives me a lot of false positives. You can always pick and choose individual types of warnings from the -Wextra category.
(Score: 2) by coolgopher on Wednesday May 10 2017, @06:02AM (7 children)
Whenever I set up a new C/C++ project, I tend to go through the latest info page for gcc/clang (or other compiler I'm unfortunate enough to have to use) and enable everyone unless I explicitly know I don't want it. And in most cases I still want that warning enabled globally, and only disable it temporarily within a compilation unit on an as-needed basis. The compiler is your best friend, listen to it! :)
(Score: 2) by TheRaven on Wednesday May 10 2017, @09:18AM (4 children)
sudo mod me up
(Score: 3, Informative) by mth on Wednesday May 10 2017, @10:22AM (2 children)
-Wextra does not enable every warning. The GCC man page reads:
Note that some warning flags are not implied by -Wall. Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. Some of them are enabled by -Wextra but many of them must be enabled individually.
It does enable a useful set of warnings, in my opinion, so "-Wall -Wextra" is a good starting point for most projects.
(Score: 2) by TheRaven on Wednesday May 10 2017, @11:28AM (1 child)
sudo mod me up
(Score: 0) by Anonymous Coward on Wednesday May 10 2017, @05:05PM
That is clang only and enables all warnings and other things. In fact, it enables so much, that the original idea was that it was only really useful in the development of clang itself; that is, when they run clang against their test suite.
(Score: 2) by coolgopher on Wednesday May 10 2017, @12:23PM
Nope, it does not. It enables *some* extra warnings, but not all. See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [gnu.org] for details. Things like -Wundef, -Wshadow, -Wfloat-equal and -Wpointer-arith need to be explicitly enabled.
(Score: 2) by Wootery on Wednesday May 10 2017, @12:17PM (1 child)
only disable it temporarily within a compilation unit on an as-needed basis
Or, if you don't mind using a more intrusive approach, stop the false-positives by putting #pragmas around the code where you really do want to do something funky. [stackoverflow.com]
(Score: 2) by coolgopher on Thursday May 11 2017, @04:02AM
That is precisely what I mean when I say "within a compilation unit" :)
(Otherwise I would have said "for a particular compilation unit")
Gcc sure took its sweet time to get push/pop support for warnings, but these days it's fully functional, thankfully.
(Score: 2) by mth on Wednesday May 10 2017, @10:36AM
I don't know if this is the "official" definition, but static analysis is anything that examines code and reports about it without running it. It could be a tool that flags coding style violations, copy-pasted code, use of error-prone API calls, known dangerous language constructs etc. And indeed compiler warnings are also a form of static analysis.