Software Integrity Blog

Author Archive

Peter Dillinger

pdillinger

After graduate work at Georgia Tech and earning a Ph.D. at Northeastern, Peter Dillinger joined Coverity in 2009 with a focus on Java static analysis. Peter quickly became a lead engineer in unifying the Java, C#, and C++ analysis engines. He made key contributions to initial support for web app security analysis and JavaScript analysis. Since Synopsys acquired Coverity in 2014, Peter has become a manager in the Seattle office, leading initial static analysis support for PHP, Python, Ruby, and now Swift, but occasionally finding time to design and implement new checkers.


Posts by Peter Dillinger:

 

Swift: Close to greatness in programming language design, Part 3

Welcome back Ahead of Coverity Static Analysis support for the Swift programming language, we are examining design decisions in the language from the perspective of defect patterns detectable with static analysis. Before digging into Part 3, I recommend reading Part 1 and Part 2 in this series if you have not already. Defect patterns part 3: heavy Now we consider defect patterns that I consider “heavy” because they are either a challenge in language design, a challenge in static analysis, or both. And many of these defects are quite common in production code. Avoided: monitor-style parallel programming bugs Languages like C# and Java were designed from the start for parallel programming via threads, locks, and monitor variables. This “wrong by default” paradigm is an almost limitless source of programming errors, many of which can be detected with static analysis. Just as one example from real code:

Continue Reading...

Posted in Software Architecture and Design, Static Analysis (SAST) | Comments Off on Swift: Close to greatness in programming language design, Part 3

 

Swift: Close to greatness in programming language design, Part 2

Ahead of Coverity Static Analysis support for the Swift programming language, we are examining design decisions in the language from the perspective of defect patterns detectable with static analysis. To kick things off, I recommend reading Part 1 in this series if you have not already. Defect patterns continued: More basics Now we consider additional defect patterns that I would classify as “basic,” because they are clearly avoidable with good language design and relatively easy to detect with static analysis. However, these are generally more common in code written by experienced programmers than the patterns we saw in Part 1. Avoided: Conversion after operation Expressions in C-derived languages are generally typed from the inside out, which can lead to unexpected bugs, trivialized in these examples:

Continue Reading...

Posted in Software Architecture and Design, Static Analysis (SAST) | Comments Off on Swift: Close to greatness in programming language design, Part 2

 

Swift: Close to greatness in programming language design, Part 1

As we are taking our first steps toward a Static Analysis solution for the Swift programming language, I am discovering one of the most challenging languages yet for Coverity. This is simply because many of the easy-to-make, easy-to-find mistakes in other programming languages were designed to be difficult or impossible in Swift. However, some mistakes that could easily have been excluded were not. Swift is a very good language that easily could have been great. Background Coverity was founded on a static bug-finding tool for C/C++ that uniquely balanced false positives and false negatives, held no reverence for soundness, and scaled nearly linearly to analyzing large codebases. It was the killer app for many large-scale must-be-correct C++ development shops, such as Synopsys, who after years as a loyal customer acquired Coverity as a company in 2014.

Continue Reading...

Posted in Software Architecture and Design, Static Analysis (SAST) | Comments Off on Swift: Close to greatness in programming language design, Part 1