4 ms·
Tooling requires a lot of effort from every programmer too, it cannot work on the scale you are talking about. On that scale compatible memory-safe C compiler o
by zzzcpan 10y ago
Tooling requires a lot of effort from every programmer too, it cannot work on the scale you are talking about. On that scale compatible memory-safe C compiler or transpiller are pretty much the only options, since gcc and llvm don't care about that.
- pron 10y agoI don't think we can guarantee the absence of that kind of errors from all existing billions of lines, but the work is still far cheaper than switching languages. New projects can make use of sound static analysis from the get-go, and old projects can apply them incrementally.
- zzzcpan 10y agoAnything we can't guarantee statically we can check at runtime, which is what memory-safe C compilers do. But this is something OS distributions can use on all of the C packages. What you are suggesting is an effort that each and every project has to take and this simply doesn't scale much better than switching languages.
- pron 10y agoI do think that sound static analysis tools are far cheaper than adopting a new language, and they can be used incrementally (i.e., lesser guarantees are cheaper), but sure, memory-safe C compilers, too! (I'm just not familiar with the approach; links?) My point is that there are solutions that we can start applying today short of rewriting in new languages, or at least until we rewrite.
- zzzcpan 10y agohttps://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://sva.cs.illinois.edu/index.html http://sva.cs.illinois.edu/index.html http://chrisseaton.com/plas15/safec.pdf http://chrisseaton.com/plas15/safec.pdf
- pron 10y agoLooks interesting and I see that some of the solutions use static analysis, too, but your links are all academic projects. Are there any production quality memory-safe compilers yet?
- fauigerzigerk 10y ago>I do think that sound static analysis tools are far cheaper than adopting a new language For new projects I don't really see why that should always be the case. It probably depends on the type of project, on the organization, on any integration requirements and on the willingness of developers to make the change.
- pron 10y agoLet me put it this way: adopting such analysis tools is about as costly as adopting a new unit testing framework. But you're right, the cost of adopting a new language depends on many factors.
- lawnchair_larry 10y agoStatic analysis does not do a great job of solving the problems with C. It is great for finding 1994-2004 era C vulnerabilities. It's rather useless at finding the problems we deal with today. To do so requires complete intraprocedural analysis and overcoming NP hardness.
- pron 10y agoSound static analysis can prove the absence of all undefined behavior. The theoretical problem isn't NP-hard but uncomputable in general, but that doesn't matter as most real instances are easy, and most of those that cannot be completely automatically proven can be proven with the addition of some annotations by the user. In the worst case, some sound static analyzers would fall to a manual proof in a proof assistant -- which is, undeniably overkill and very costly -- but even without it, the number of bugs is reduced almost to zero, and the places that the analyzer cannot prove are reported.