4 ms·
Anything 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
by zzzcpan 10y ago
Anything 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.