Software Integrity Blog

 

Don’t Panic: Write checkers using CodeXM

Don’t Panic: Write checkers using CodeXM

With apologies to the late Adams Douglas Adams, writing a checker is hard. You just won’t believe how vastly, hugely, mind-bogglingly hard it is. I mean, you may think it’s difficult to pull together a purchase order for a new bit of software, but that’s just peanuts to writing a checker.

Truth be told, writing a good checker does take a lot of effort.

Or rather, it used to. Coverity® represents literal person-centuries of software scientists’ and highly trained experts’ efforts writing finely tuned checkers. But with the advent of Coverity CodeXM (pronounced “code exam”), writing certain kinds of checkers just got a whole lot less hard.

In fact, it’s become downright easy. Maybe even fun.

A small team of experts has taken all our experience writing checkers—plus what we know about writing tools that help write checkers—and distilled that into this new language. We’ve also added one essential ingredient that wasn’t present before:  It’s easy to learn and easy to understand, but still powerful enough to solve some hard problems.

Take a look at CodeXM

To illustrate the point, let me throw this tiny snippet of CodeXM at you to see if you can figure out what it does (even without knowing the first thing about the language):

  include `C/C++`;

  checker {
    name = "NO_GOTO";
    reports =
      for c in globalset allFunctionCode
        where c matches gotoStatement: {
          events = [
            {
              description = "Use of "
                          + c
                          + " is not allowed";
              location = c.location;
             }
          ]
       }
  };

Think you know what this checker finds? That’s the point: While you’ve almost certainly never seen the syntax before, you can form a pretty good idea about what it does, based on your existing programming experience.

Wait, you want me to write checkers?

OK, your job as a software developer is to write code, but naturally that means your code, not checker code.

Don’t panic! We understand that. You use Coverity day in and day out, and it does a great job of finding problems in your code. And you know where your towel’s at, so you’re perfectly happy keeping your involvement to a minimum. Examine what Coverity finds. Fix your code. Done.

“Still,” you think to yourself, “wouldn’t it be great if Coverity could be tweaked to run one little check specific to this project?”

Well, mention “SDK” or “new programming language,” and most developers justifiably break out in a cold sweat. There’s too much of one’s own code to write, and too little time to write it in, so who has the time to learn how to write a checker?

Yeah, we got that. We designed CodeXM to keep the amount of stuff you need to learn to an absolute minimum. Recognizing that you’ll likely write one checker at a time and then just let it do its thing (forgetting everything in the meantime), we made CodeXM easy to learn and easy to pick up again later. You don’t want to spend a bunch of time away from writing the code that earns you your paycheck—and we don’t want you to, either.

Easy to use? So it can’t do much, right?

Actually, CodeXM can do quite a bit. It is the underpinning of much of our MISRA and CERT C compliance suites, as well as a number of other checkers we have made available. So we are constantly adding features to make it more powerful. The bonus is that from day one, we have put in a lot of extra effort to make the language expressive, self-describing, and powerful without your needing to get a Ph.D. in software verification to comprehend arcane concepts.

So think it over. Writing your own custom checker using CodeXM may not be as hard as you think. And that special checker you’ve been wishing Coverity had—well, you might be able to make it happen. Trust me: It won’t be anywhere as hard as getting to Milliways.

Join the conversation:
Learn more and ask questions in the Software Integrity Community

 

More by this author