The later bugs are introduced, the more they cost. Of course, common sense. But it also happens to be true.

As the chart shows, very little bug detection is happening before testing, while a developer is coding. So, if you find more bugs when the cost of repair is least expensive and risky, you’re obviously going to get a big payoff.

Ok, so far you haven’t heard anything that every software development professional doesn’t already know. What everyone doesn’t know is that source code analysis can deliver this payoff.

We just published a few new case studies from Canfield Scientific, Overture Networks, and Polycom. Here’s a sampling of what these customers are telling us about the benefits from using Klocwork:

“Our code is more stable and reliable today, and I would say we are in a best-in class category when compared to other software companies in the industry. We can see this when development starts new coding and there is a very minimal dip in stability. Development also recovers faster and starts working on new products faster.”

“Many of our developers use Visual Studio and like the ability to see and address potential problems on-the-fly from their desktop. It’s not an intrusion for them – they find it to be a big time saver.”

Impressively, within just a few months of use, Klocwork Insight had resolved a major field issue that the company was dealing with. Even more critically, “Klocwork Insight also found three other bugs that had caused several field outages – this is a very significant achievement for us.”

Check out these case studies in full, and you’ll see how the benefits these customers are realizing all go back to the chart above – find issues earlier, make your developers’ lives easier, reduce costs, and build better software. Great to see our customers achieving these results!

This is where I take a deep breath as I scream on the inside. Taking every bug and putting that into your bug tracking system is just wrong. Horribly wrong.

The best way I can describe this is through the compiler analogy. Every time you add a feature or bug fix, you run your compiler. Your compiler complains, saying you have a syntax error and you just fix that, rinse and repeat.  Would you ever send your syntax errors to your bug tracking system? Uh, no. So why do the same for static analysis? Just because it is a critical buffer overflow or memory leak? No.

Why impose any kind of workflow for the developer when it comes to bugs? There should only be one thing the developer has in mind. Either fix the issue or ignore it. Just like they do for any syntax error from the compiler.

This is really a discussion of your usage of your static analysis (or source code analysis) tool.  What I’ve described is the process where the developer is using static analysis at the desktop, in their favorite text editor or IDE. Of course, there is an exception to this. You can use static analysis on the full system run only. I highly discourage this for various reasons but I’ll save that for another discussion.

The chances are that you could have a product that is already established, so you probably have a backlog of issues.  Static analysis can certainly be used to triage these bugs and output them to your bug tracking system.

I hope my message is clear, if you use static analysis correctly (allowing the developers to fix bugs as they create them) and a bug appears, just plain fix it.  Yes, it’s that simple.

Two Different Spell Checker Usability Models

On the surface the difference looks subtle but the changes are huge. The first scenario required the user to take action, interrupt their workflow, and was a “separate” activity from writing a document. The usability model we’re all familiar with now is naturally incorporated into a writer’s workflow. It still does the same thing: it checks your spelling against its dictionary, provides suggestions, and will auto-correct for you. But the difference in ease-of-use and end-user adoption of the technology has obviously been huge.

That’s what we’ve done with static analysis. We’ve taken a complex analysis technology that used to only live at integration build time, moved it down to the desktop in 2008 (much like the usability model on the left above), and now with Klocwork Insight 9.5 have introduced the model to the right. Here are some links to short Klocwork Desktop Analysis for Visual Studio demos showing this capability in-action.

The next question we tackle here is: What is my cost of ownership?

The answer, my friend, is not blowing in the wind, it’s in your Complexity Trend report:

Complexity Trend report

Why there? you might ask. Well, it’s because there’s a straight-line correlation between the complexity of a function and its cost per line to code and test.

If we see an increase in the Complexity Trend, we can use Complexity Details to pinpoint modules or files containing the most complex methods:

Complexity Details report

Looking at this report, I can see where my ownership cost is localized. More often than not, we find that the modules that contain the most defects are also those that contain the highest number of  complex methods.

Klocwork Insight metrics use McCabe Cyclomatic Complexity to assess the complexity of a program.

Another indicator of the high cost of ownership is the point at which defects are caught and fixed. Finding and removing bugs as early as possible in the development cycle lowers your ownership costs. This report shows fix activity between builds. You can toggle between views showing fix activity in the integration build and on the desktop. For now, we’ll look at All fix activity:

Fix activity by module

Here we see a spike in activity that occurred during the start of a new feature release.  If the upward trend continues, it can indicate a couple of scenarios. Either:

• Your development team is growing and more developers are using static analysis on the desktop, or
• Your team size is the same but developers are using static analysis more consistently.

Either way, more activity means more value from the tools and a lower cost of ownership. Developers fixing defects before check-in lowers your cost of ownership considerably.

Any more questions?

I’ve had discussions with customers where they tell me 80% of all their defects are false.  Odd, I know static analysis tools today are much, much better than that.  In fact it usually tends to be the other way around — 80%+ are real.  So in situations like that, you have to analyze the defects further.  After analyzing a few I can see many have been marked as “false positives” even though they are real.  When I challenge the customer it fits into either one of two categories:

1. I don’t care, that will never happen in my lifetime.

2. You’re wrong.

For #1, not everyone believes in defensive programming.  In some cases it doesn’t even make sense, in others I’ll still argue that it is important.  For example a customer once told me that the memory leak we identified is real but they don’t care, because it is initialization code.  Meaning when it starts, it leaks memory but it is closed off shortly after that.  I understand that sometimes you don’t have time to address every single issue, but what if someone decides to learn from you and copies that code.  Or later that code turns into something more than initialization.  It will happen.

For #2, typically the customer believes we are outright wrong.  Certainly in some cases we are, but in others we are just not providing the proper tools for the developers to understand the issue.  The best tool for that is what’s called “traceback”.  Traceback provides you clear instructions on the conditions and assignments of any detected defect.  One of my favorite examples is a buffer overflow.  The traceback below shows you the size of the array and where you are exceeding the bounds of that array.

In this example, it says we exceed that bounds by 15 (we are accessing the array from values 0-65).  The obvious question now is where on earth do you come up with 65?  When we expand the traceback, we can see the full details of that calculation.  The traceback proceeds through the details of every expression until we arrive at the right value, in this case 10+10+10+10+10+10+5=65.

False positives may be a way of life but when addressing them it is important to make sure you are not looking at a perceptual false positive.  The traceback tool is helpful in assessing not just perceptual false positives but other identified defects as well.  It will only make your life easier.

First, Klocwork Insight 9.5 won its first award: the Military Embedded Systems Editor’s Choice. Here’s an excerpt from their write-up:

Software developers have enough on their plates without having to spend undue time analyzing their code. Sure, there is traditional source code analysis, whether done manually or by using techniques such as static or dynamic analysis, but Klocwork’s Insight 9.5 is intriguing because it strays away from the centralized batch-processing analysis modus operandi and instead implements on-the-fly, as-it’s-created code analysis.

Also last week, Klocwork Insight was one of 5 products to be awarded with CWE’s Official Certificates of CWE Compatibility.  This means our customers can rest assured that our products are “CWE Compatible”, based on CWE’s own criteria. Great news for all our customers who care about creating more secure code!

Klocwork Insight 9.5 was also a finalist for the Embedded World Award 2012, losing out in a close fought battle (so I’m told:) to Windriver and Willert for their software development tools. Congrats to the winners!

And that’s just in the the last few weeks since we launched the product.

Speaking of Embedded World, what a great event that was last week. Aside from the vast quantity of Nurnberg sausages we all ate, the sheer size of the event and quality of attendees was top-notch. The whole Klocwork team was run ragged all week hosting a customer event, doing demos at the booth, meeting partners, and just generally getting the word out.

So, good stuff all around for a product that was released barely one month ago!

Think Magic 8 Ball with build omniscience and powerful reporting tools. OK, maybe Magic 8 Ball isn’t a good analogy.

Answers to what questions, you ask? One we often hear from customers is: Where do I start?

A good place to start is a report that captures the distribution of defect types from your current build.  For example, we recommend that our customers glance over the Top 10 Issues report in our web-based build reporting tool, Klocwork Review while indulging in their morning cup of coffee:

Magic 8 Ball can't do this. Here's a defect distrubtion view of your build.

With this build snapshot and your caffeine jolt,  you can quickly identify defects of interest to your organization, such as null pointer dereferences and memory leaks. If you wish, you can set up filters (we call views) to show only these defect types in your report.

Your next step is to get your developers using static analysis on their desktops to prevent the injection of these high-priority defects into the build in the first place.

Once a policy of pre-checkin static analysis usage is put in place, pay attention to new defects injected into the build from that point on. If you see a spike in new defects, then investigate.

The magnitude of that y-axis is not what matters most; it’s the overall trend that counts.

For my next post, I’ll take a look at reports that track your cost of ownership and show you what success looks like.

In this post, we’re going to use a custom checker to enforce an internal coding standard that extends the default set of checkers in our source code analysis tool.

To do this, I’ve called upon Steve Howard, our head of Partner Support in Europe, to get us started with an AST checker to accomplish our goal.

Steve has coached many customers through the checker creation process. In his experience, the appeal of custom checkers lies in their ability to enforce naming conventions and code constructions across organizations.

The standard we want to enforce is the use of a compound statement block rather than single statements as the body of a for loop. An AST checker is the way to go because detection depends solely on the syntax of the code itself and not runtime behavior.

See the example below:

To flag this violation, we need to instruct the checker to find all instances of for loop nodes that contain a Statement node as an immediate descendant.

A tool that shows you a visual representation of the AST for the test case is quite helpful in the checker creation process. Here at Klocwork, we use Checker Studio to:

• browse the AST structure of test cases,
• identify nodes of interest, and
• test XPath-like expressions that identify node types, qualifiers, conditions and variables to traverse the AST and flag the defect.

Note: If we wanted to enforce the compound statement rule in all loops, then we’d need to have one pattern (created using the XPath-like expression) for each possible kind, such as while loops and do while loops.

Armed with the test case, Checker Studio, and a syntax guide, Steve identified the following expression that flags the infraction:

// ForStmt [not (Stmt::CompoundStmt)]

Here’s how the test case and expression appear in Checker Studio:

Golden rules

Based on his experience, Steve has a number of golden rules that get you from idea to defect detection faster:

• Start simple: Use a simple test case that contains the defect you want to detect and work with one simple pattern at a time. Add more complexity as you go along
• Start rough and refine later: Don’t worry about false positives at first. In some cases it may even be easier to search for  instances that are OK and then negate the rule at the end
• Divide and conquer: With a more complex checker, work separately on each aspect of the defect you want to detect and then bring it all together at the end for testing in Checker Studio
• Watch your levels: Make the highlighting as relevant as possible for the issue you’re trying to find. For example, “// ClassType [MemberDecls[*]::MemberDecl]” will highlight classes that match, whereas “// ClassType/MemberDecls[*]::MemberDecl”  will highlight class members that match. The rule is the same, but the focus is different
• Weed out false negatives: Add negative examples (good code) to check for false negatives

For more information about our custom AST checkers, watch our Checker Studio video.

Answer: Klocwork Insight 9.5 releases today and boy are we ever happy to see it go live — we’re “out there Jerry” and yes, of course we’re loving every minute of it.

This has been a long release, taking significant research and development to bring to fruition, all the while continuing to release more traditional shipments as we went, but finally culminating in a new, game-changing technology for source code analysis. On-the-fly, as-you-type, instant-like-for-reals, call it what you like… full-on, in-depth C/C++ analysis performed as the developer enters their code, using the “squiggly line” usability metaphor created by spell checkers. It’s one of those “why would you do it any other way” moments and we’re happy to be unique.

Not to be outdone, our web tools team has done amazing stuff with a complete redesign of our Review and Inspect tools, showcasing an awesome look and feel that leverages the toys that come with HTML5 and, amongst many other new capabilities, brings drag/drop pivot report design to the web for on-the-fly metrics and trending analysis that managers and development leads will just eat up.

To our customers, our partners and our friends in the industry, we’d like to say Welcome to Insight 9.5, hope you enjoy it.

You’ve been using source code analysis on your integration build or your desktop, or (ideally) both. And then there’s “a situation”.

The situation

Either you:

• Noticed a false negative you want detected, or
• Need a way to enforce a corporate coding standard, such as the requirement for the use of  a compound statement block rather than single statements as the body of a loop.

Now what?

Time to create a custom checker, that’s what. But what kind of checker?

Source code analysis involves two families of checkers, those that involve:

• Abstract Syntax Tree (AST) validation, and
• Code path analysis.

An AST provides a tree-based structural representation of the source code. An AST checker allows you to pinpoint problematic syntax using XPath or XPath-derived grammar to define the problem you’re looking for. AST checkers (our version is called Klockwork AST checkers, or KAST for short) don’t require program execution to run; they detect defects right away on source code.

Code path analysis, on the other hand, targets defects related to value tracking at program execution time. Instead of style violations, you’d use a path checker to answer questions such as:

• Is this newly-created object released before all aliases to it are removed from scope?
• Is this data object ever range-checked before being passed to an OS function?
• Is this string checked for special characters before being submitted as an SQL query?

To create a path checker, you don’t need to know how data is tracked by the checker. What you do need to know are the function types and values you want to track for the analysis starting point and the analysis end point where the defect (or event) is recognized and reported.

Which checker when?

Create an AST checker when the problem you want to detect:

• is a local defect
• does not involve program execution
• has to do with the way the program was written
• does not involve tracking a value
• does not involve a path

Create a path checker when the problem you want to detect:

• involves tracking a value
• has a starting point (where the analysis starts) and end point (where the defect is detected)
• involves program execution

Stay tuned for the next post in this series on best practices for AST checker creation.

For more information, see Writing custom checkers with Klocwork Extensibility or check out our member discussions in the C/C++ custom checkers forum.

–With files from CTO Gwyn Fisher

To add another twist to this story, the researcher in question has been ejected from participating in Apple’s developer programs. Read about that here.

Are we now getting to the point where hackers are going to start trying more aggressively to exploit Apple products? In a survey done in 2010, over 50% of respondents thought Windows was either “very” or “extremely” vulnerable compared to only 20% for Apple. I wonder if that has changed? More importantly, do I need to start worrying about my daughter downloading the Archie comic app from the App Store?

A number of years ago, one of the projects I was PM on decided to try out Scrum. I had attended some Product Owner training, and our soon-to-be Scrum Master had been on some training as well, but we were very green and decided to approach things with a “let’s see what works best for us” mentality. At the time, we thought the best way for us to get immersed and efficient with Scrum was lots of repetitions. We went with 1-week iterations, thinking that by having a rapid and regular cycle of sprint planning meetings, demo meetings, retrospective meetings, etc. we would learn more quickly the “proper” way of doing development with Scrum.

We certainly did learn a lot during our first 3 or 4 sprints, mainly that having this regular weekly cycle of meetings was just too much overhead, and the actual amount of value produced at the end of each sprint was too little. Next on our list, the 2-week sprint.

The 2-week sprints worked great for us, and we saw the differences from the 1-week sprints almost immediately. We were producing what we thought was a good amount of value from each sprint, but with a better and more balanced level of overhead. We hit our groove and established a good cadence with these 2-week sprints, and from the looks of the burn-down chart, we were becoming a more efficient team with every sprint.

The team definitely was cruising and enjoying the pace, but the holiday season snuck up on us and we thought that it might make sense to make some adjustments to deal with the vacation time various team members would be taking.

After collecting everyone’s vacation schedule, we were able to determine a start and finish date for our “holiday sprint” that would essentially start when everyone was still in the office, and finish when everyone returned from their vacation. Call it either luck or good management, but we had planned a 4-week sprint. I won’t go through all the gory details, but let’s just say that upon reflection, the 4-week iteration just felt wrong.

The initial planning session felt harder to estimate the amount of work we could do. The cadence we developed didn’t show itself, and it really felt like we never gained any momentum during the 4 weeks. Now I’m sure that the whole holiday season thing played a role in this, but it was our least effective iteration ever, and by a lot. We never tried the 4-week iteration again.

The bottom line is that all teams are different and need to go with the iteration length that feels right for them. For us, the 2-week one was best.

For the record, I have always wondered if the 7-year rule for chewing gum was true. Glad to hear it isn’t.

Under the covers, do you really know what is happening with your compiler?  Not usually.  You make changes to your code, call your compiler or build command to compile your code, and then fix the issues.  Rinse and repeat.

But what is really important for static analysis tools, is that the compiler contains some crucial information to successfully compile your code.  Namely, the internal compiler includes and defines.  Static analysis tools must generate this data, otherwise they won’t know where the system includes and defines are coming from for your specific compiler.  Hence, the static analysis results are about as accurate as the weather man’s weekly prediction.

Luckily most compilers have a way to capture this.  For example to find out the defines and includes from gcc:

gcc -E -dM dummy.c

gcc -E -Wp,-v dummy.c

Where dummy.c is just an empty file.  This will give you a dump of all the defines and includes, respectively.  Now, when static analysis tools build their data they have a mapping of the proper defines and includes for your specific compiler and everyone is happy.

In the past, it seemed like a good idea to make compiler configuration extensible.  This meant that static analysis tools could support any compiler if you didn’t mind taking the time to build that support.  It wasn’t usually very complex but it could be prone to errors.  Instead, it makes more sense to just provide the support right out of the box, so taking the words from the late Steve Jobs: “it just works“.  As long as static analysis tools have an extensible interface, these tools should be able to support new and obscure compilers very quickly.  Make sure your static analysis vendor has support for your specific compiler that you use, and if they don’t they better turn that around in a snap.

With all of the inherent challenges for agile in these organizations such as standards/regulatory compliance, hardware changes and integration, security issues, etc. I must say that I’m a little shocked that customers are moving away from their current processes towards something like agile. Add to this the fact that the Agile Manifesto specifically states “Working software over comprehensive documentation” and it doesn’t exactly sound like agile is a great fit for embedded systems in general, let alone medical device.

Now, don’t get me wrong, I am a huge proponent of agile, and I certainly realize that there are many pros for moving to agile, and these have been well documented, but I have to wonder just how agile are these specific industries going?  I would bet that most (all?) of these organizations are adopting some of the key fundamentals of agile, but to say they are going “all in” would be a bit of a stretch.

Even industries heavy on process (because of regulatory requirements) are taking the leap into agile. How agile are they?

Looking at the manifesto a little closer, some of the principles are fairly generic and feel more like common sense than anything revolutionary, so they probably apply to any industry. There are a few principles however that are fairly easy to imagine in these industries, such as:

• getting all stakeholders involved in defining requirements (Principle #4), or
• embracing more face-to-face conversations (Principle #6), and
• simplicity, or minimizing the amount of work not done (Principle #10).

But do people really think that Principles #1 (early and often delivery of software), and #2 (welcome changing requirements) really apply to the embedded or medical devices industries? Personally I don’t see it.

So what do you think? Are the embedded software or medical devices industries capable of going full out Agile?

You can use the banned.h file to identify and obtain deprecation warnings or, even better, use this as part of your source code analysis.  Leveraging these warning as part of your source code analysis solution means you have better ways to filter and manage the solution as opposed to a dump of potentially thousands of warnings.  Add that into your code review tool and you have some good discussion points for your peer code reviews.

Like any security guideline, the question becomes how useful are these?  There is no question that these banned functions are debatable.  The complaint that I hear the most is that “n” functions can be used safely so they should not be part of the list.  But you can still get yourself in a whole heap of trouble with these functions as well.  Take this example from Micheal Howard’s blog:  Buffer Overflow in Apache 1.3.xx fixed on Bugtraq – the evils of strncpy and strncat!.

I believe there is merit in identifying these functions so you can ask yourself if you’re using them securely.  For more information and training on the Microsoft SDL you can look at the course “Intro to the Microsoft Security Development Lifecycle” on our web page.

Is anyone out there using the Microsoft banned function list religiously?

Well, we agree. That’s why we’ve partnered with our friends at Security Innovation to make some of their developer eLearning courses available for free on the new, revamped Klocwork University. I encourage you to check out the Secure Coding for C/C++ course – it’s approx 60 minutes in length, features interactive material, and is a great introductory course into many of the key concepts required to build secure software. We also have a course on Microsoft’s Secure SDL and the OWASP Top 10. Check it out!

Klocwork University is your one stop for self-paced online learning and how-tos about:

• Setting up and using our static analysis tools on your desktop or integration build
• The latest trends in software security
• Agile coding practices and how they intersect with static analysis
• Klocwork product overviews

At Klocwork University you’ll see helpful descriptions of:

• In-house and partner-generated e-learning courses
• Video how-tos
• Webinars

After you browse our offerings on the Klocwork University page, click your selection and access your resource. If you’re not already logged in to the Klocwork Developer Network, you’ll be prompted to log in or register to use these free resources.

This change pulls the course content descriptions from behind the login wall to provide a searchable list for members and non-members alike.

At Klocwork University, you get the information up front and you can schedule your pub breaks when and where you want. Join today. There’s no free beer though.

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   try {
12     Connection conn = DriverManager.getConnection(dbUrl);
13     PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
14     stmt.setString(1, id);
15     ResultSet rs = stmt.executeQuery();
16     while (rs.next()) {
17       result.add(rs.getString("code"));
18     }
19   } catch (SQLException e) {
20      e.printStackTrace();
21   }
22   return result;
23 }

The problem with the code above is that it allocates SQL server resources but fails to properly release them. More specifically:

• Line 12: SQL connection ‘conn’ is not closed on exit.
• Line 13: SQL object ‘stmt’ is not closed on exit.
• Line 16: SQL object ‘rs’ is not closed on exit.

The next snippet illustrates how one can fix the defects listed above:

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   Connection conn = null;
12   PreparedStatement stmt = null;
13   ResultSet rs = null;
14   try {
15     conn = DriverManager.getConnection(dbUrl);
16     stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
17     stmt.setString(1, id);
18     rs = stmt.executeQuery();
19     while (rs.next()) {
20       result.add(rs.getString("code"));
21     }
22   } catch (SQLException e) {
23     e.printStackTrace();
24   } finally {
25     if (rs != null) {
26       try {
27         rs.close();          // close() throws an exception...
28       } catch (SQLException e) {
29         e.printStackTrace(); // ...have to catch it to free 'stmt'
30       }
31     }
32     if (stmt != null) {
33       try {
34         stmt.close();        // again, close() throws an exception...
35       } catch (SQLException ignore) {
36         e.printStackTrace(); // ...have to catch it to free 'conn'
37       }
38     }
39     if (conn != null) {
30       try {
41         conn.close();
42       } catch (SQLException ignore) {
43         e.printStackTrace();
44       }
45     }
46   }
47   return result;
48 }

The code above is correct but extremely verbose. However, it can be improved without sacrifices in semantics…

Tip #1: It is better to allocate a resource before the ‘try/finally’ block, not inside it. Let’s start with the following code:

Connection conn = null;
try {
  conn = DriverManager.getConnection(dbUrl);
  // use conn
} finally {
  if (conn != null) {
    conn.close();
  }
}

can be rewritten as:

Connection conn = DriverManager.getConnection(dbUrl);
try {
  // use conn
} finally {
  conn.close();
}

Tip #2: Use nested ‘try/finally’ blocks if you allocate a sequence of resources. Let’s start with a snippet:

try {
  Connection conn = DriverManager.getConnection(dbUrl);
  PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
  try {
    // use conn
    // use stmt
  } finally {
    try {
      conn.close();
    } catch (SQLException e) {
      e.printStackTrace();
    }
    try {
       stmt.close();
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }
} catch (SQLException e) {
  e.printStackTrace();
}

How many problems have you noticed in the snippet above? I found three:

• Allocation of resource ‘stmt’ can throw an exception before we enter the outer ‘try/catch/finally’. If happens ‘conn’ will never be freed.
• We duplicate code for the SQLException handling. We were lucky to have only one line of code replicated, but it in general cases exception handling can be a bit more involved that we see here…
• The order of resource allocation does not match the order of deallocation: here the order of deallocation should be reversed to be correct.

The only robust way to handle resource allocation/deallocation and to address the issues listed above is to use nested try/finally blocks:

try {
  Connection conn = DriverManager.getConnection(dbUrl);
  try {
    // use conn
    PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
    try {
      // use stmt
    } finally {
      stmt.close();
    }
  } finally {
    conn.close();
  }
} catch (SQLException e) {
  e.printStackTrace();
}

Let’s apply tips #1 and #2 to our original method and fix the resource leaks on lines 12, 13, 16:

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   try {
12     Connection conn = DriverManager.getConnection(dbUrl);
13     try {
14       PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
15       try {
16         stmt.setString(1, id);
17         ResultSet rs = stmt.executeQuery();
18         try {
19           while (rs.next()) {
20             result.add(rs.getString("code"));
21           }
22         } finally {
23           rs.close();
24         }
25       } finally {
26          stmt.close();
27       }
28     } finally {
29       conn.close();
30     }
31   } catch (SQLException e) {
32     e.printStackTrace();
33   }
34   return result;
35 }

This is way shorter than the original solution!

Tip #3: If after applying tip #2 you feel that all your code drifted way too close to the right page margin it means that you probably have too much nested ‘try/finally’ blocks and that is time to check if you actually want to have all the resources allocated at the same time. Chances are that you do not need them all; otherwise use the Extract Method refactoring pattern to move out some of the resource access logic.

Tip #4: Know specific behavior of resources you are dealing with. While tips #1 – #3 provide a robust and compact approach for dealing with resource allocation/deallocation in general, in certain cases you can make code even more compact. In our example: Statement.close() closes its current ResultSet object if one exists. Likewise Connections.close() releases JDBC resources. It means that if you deal specifically with JDBC it would be sufficient to close the ‘parent’ resource to be sure that all ‘subresources’ will be properly released:

09 List<String> requestCodes(String dbUrl, String id) {
10   List<String> result = new ArrayList<String>();
11   try {
12     Connection conn = DriverManager.getConnection(dbUrl);
13     try {
14       PreparedStatement stmt = conn.prepareStatement("SELECT * FROM customers WHERE id = ?");
15       stmt.setString(1, id);
16       ResultSet rs = stmt.executeQuery();
17       while (rs.next()) {
18         result.add(rs.getString("code"));
19       }
20     } finally {
21       conn.close();
22     }
23   } catch (SQLException e) {
24     e.printStackTrace();
25   }
26   return result;
27 }

One very clear message from all the partners was that our MISRA support was a huge plus.  Here in North America we have seen small pockets of adoption, but in Europe and even Asia it used quite a bit.  As we have mentioned in the past, it is not only automotive organization but all levels of business.

Soon MISRA C 2011 will be released.  Look forward to seeing all the changes especially with the added support of C99.

It would be very interesting to hear of some of the Armed Services and Intelligence cyber threats that the government has not publically disclosed.  That might be an eye opener.

Michail the friendly, programming vampire.

Instead of fomenting dissent (that barely exists) in a brazen attempt to boost readership, I’m changing tactics to look at ways in which testing and development are complementary, beyond their common goal of releasing quality software products.

What can I say? After my previous post, How developers drive testers nuts–let’s count the ways, I’m clearly getting less edgy.

I approached our newest addition to the Klocwork development team, Michail Greshishchev. While he’s a new full-timer, Greshishchev is not a new face around here.

The recent Carleton University engineering graduate did two co-op terms here–one in professional services and the other in testing.

So I asked Greshishchev how his stint in testing affected his development. Here’s exactly what he said:

1. Writing short, efficient unit tests comes naturally after dealing with mammoth testing frameworks. Most of the code I write are tests – the techniques and skills I’ve learned in testing are fully applicable to development.
2. Developers have no idea how to execute a test in our automated test system (I don’t blame them–the test machine is a large, well-oiled beast distributed over dozens of operating environments). Having the knowledge to run test team tests on developer builds means I don’t need to wait for nightly build test results to address issues. More importantly, I can add my own tests to the test team’s automated test system.
3. It’s common for a developer to request more information about a tester’s problem report. My experience with the test team allows me to access the information on test machines myself, saving time for everyone.
4. The test report pages actually make sense. This allows me to investigate test failures in the nightly build before a tester comes to my desk to tell me I broke something.

His experience as part of the test team has been win-win for him and his colleagues. Testing and development sound like allies, don’t they? Well, as much as werewolves and vampires can be allies, I suppose. And he was such a nice guy too, but the change is upon him.

In addition to CWRAF and CWSS the 2011 CWE/SANS Top 25 list has been updated.  There has been a number of position changes and a few that have been knocked out and replaced by CWE-250, CWE-676, CWE-134, and CWE-759.  Not too many surprises but I never really noticed CWE-134 not in the list before.  That certainly makes sense.  However it does shock me that CWE-129 (Improper Validation of Array Index) didn’t make the list this year.  Certainly a problem that I’ve seen a ton, although it was close (#27).  To see Klocwork’s coverage of 2011 CWE/SANS Top 25 go here.

In the final post in this series, I’m going to introduce you to the present day Static Code Analysis technology and how it is impacting developers.

The Present Day

I’m a huge fan of Reece’s Peanut Butter Cups. I love them. I keep active so I don’t feel guilty eating them. In a strange, convoluted way, the 3^rd generation of static code analysis tools are like this delicious combination of chocolate and peanut butter. Let me explain.

Eureka! Now developers are able to perform an analysis locally, using their development environment of choice, while still getting the high accuracy and consistency that was previously only possible by checking in their code and waiting for the integration build to take place.

Think about the ramifications of this:

• cleaner code is being checked in
• the ‘rinse-repeat’ vicious cycle of rework is drastically reduced
• quality teams are now able to focus on testing the product’s functionality rather than spending cycles uncovering something that could easily and quickly be found by automated tools.

Mmmm-mmmm good. Sounds like a win-win-win to me!

I think the best thing about these 3rd generation tools is simply the fact that developers are now able to resume ownership of the quality and security of the code they are producing.

Well, I hope you enjoyed this walk down memory lane. I sure did. Now I’m looking for spare change because I see a trip to the vending machine in my immediate future.

If you want to know more about the 3rd Generation tools, feel free to drop me a line.

That may sound counter-intuitive. Shouldn’t a zero noise point on the spectrum be accompanied by an infinitely strong signal? Perhaps in the world of DSP this is true, but in the world of SCA reducing noise comes right along with a reduction in detection capability – it’s unfortunately almost a straight-line correlation.

So if we assume that we’re trying to balance a couple of dials on our theoretical tuner, we might start by reducing or dampening noise – it’s the most obvious place to start, after all. Nobody likes to listen to their favorite FM station through the curtain of hissing and popping that accompanies the act of driving through a major city.  Likewise no developer likes sifting through a long list of bogus detection errors in order to find the hidden gems. But to drag out the analogy, assume that the only way of reducing hiss on your FM signal is to turn down the volume… now you’ve got less hiss, but also less Bruce Springsteen goodness to accompany it.

Balance is what we need here, obviously. Enough Boss to make us ignore the hiss, or to put it in a more SCA-like context, enough interesting bugs to make us ignore the incorrect, or the irrelevant (correct detections on the part of the engine that the developer just doesn’t care about, e.g. low memory conditions in a memory-insensitive environment).

Consider the following simple example that clearly lies “on the line”:

    void foo(char* s, int a)
    {
        char* s1 = s;
        if( a > 0 )
            *s1 = 'a';   // potentially use an uninitialized ‘s1’
    }

    void bar(int m)
    {
        char *s;
        foo(s, m);       // s is not initialized prior to calling ‘foo’
    }

So… to report, or not to report?

Lacking any other information, it is obvious that function ‘foo’ interacts under certain situations (when parameter ‘a’ is positive) with parameter ‘s’ (aliased as local variable ‘s1’). As we have no knowledge about the provenance of parameter ‘s’ when analyzing ‘foo’, however, there’s nothing here to cause a report and so we squirrel away the knowledge of what ‘foo’ does for later use.

When analyzing ‘bar’ we know what ‘foo’ does, and we know we’ve got an uninitialized local pointer, ‘s’. But again we’re lacking enough knowledge to know the valid values, or ranges, that parameter ‘m’ may take. There are definitely a set of circumstances here in which we know a problem will occur (if parameter ‘m’ is positive), and a set of circumstances in which we know a problem will not occur (if parameter ‘m’ is zero or negative) – this much is encoded in the functional behavior of ‘foo’. But is it a defect, or should we filter out the report in favor of providing only those situations in which we can be “sure” the bug not only exists, but can be proven to be exercised?

There’s the art of balance in a nut-shell, and it revolves around the phrase “lacking any other information.” In the ideal world, lacking any restrictions in terms of time, memory or computing power (or indeed actual from-the-wall power, as we have to worry about now), we might defer all such decisions until we categorically know that a particular data value is passed down the call graph far enough to get to ‘foo’. But in the real world of multi-million LOC projects, that approach simply can’t scale.

And so, calling on balance as our friend, we can bias a localized decision to report or not, given that we know to at least one order of approximation that bad things could happen here. Different engines pronounce that bias differently, leading to one of the greatest divides between prevalent solutions.

Now ask yourself, as the developer, is it a worthy report if you know that 10 levels up the call graph there’s a check on what eventually becomes parameter ‘m’ to ensure that it’s never positive? Perhaps you’d automatically classify this as a false positive and, annoyed at the tool, move onto the next report. Or perhaps, seeing the size of the gap in the call graph, you might just choose to code defensively, initializing ‘s’ to NULL in ‘bar’ and adding guard code to ‘foo’ because, hey, you never know.

And as we’ve all seen so many times over the years, “you never know” might just as well be written “and so it came to pass…”

1. Determine who cares. Who has a vested interest that bugs actually get fixed. How much do they care?

2. Get an expert to tune the solution for your codebase. Static analysis tuning will maximize defect finding while minimizing false positives.
3. If possible, pilot with a small group to gain early successes.
4. Appoint the proper roles, particularly management sponsor, administrator, defect triagers, fixers and verifiers.
5. Set up the proper process, incentives and consequences. Integrate the SCA tool into your environment. Automate and simplify as much as possible.
6. Get a team to handpick good, high-priority defects for the team rather than have them sift through potential false positives.
7. Set up a central resource website that includes simplified documentation, policies, procedures, roles, reports, etc.
8. Set up various reports like the daily dashboard, top ten list and the “wall of shame”. Make it public. Do a little bit of marketing.
9. Train and mentor the team providing guidance, support and discipline. Either in-person or static analysis e-learning courses work.
10. Determine success criteria and measure it. Provide status updates often, work on a source code analysis ROI model that works for your organization.

I agree with the general thrust of most of these, but some might be overkill depending on the size of your deployment. My other quibble is that many of the recommendations presume a centralized defect triage model where you’d have a central group of code reviewers sifting though bug reports.

That’s a common deployment model, but we’re seeing more people choose to just provide the tool to their developers via desktop static analysis. With the possible exception of your backlog, this will eliminate (or greatly reduce) the need for a central code review team that stares at bugs all day long. Regardless, they’re all good considerations to at least, well… consider.

With the launch of the Klocwork Developer Network, we’re making a deliberate and concerted effort to make many of these kinds of deployment resources freely available to our customers. I’ve included links where appropriate.