What is MISRA? More Irrelevant Software Requirements Again…uh no but certainly the sentiment of many developers.  MISRA (Motor Industry Software Reliability Association) is a coding standard, which first released MISRA C in 1998 and has since been revised.  Obviously, this came out of the automotive sector with a clear focus on helping software systems to be more reliable and maintainable.

MISRA has since grown.  Now you see more and more industries adopting these standards.   In 2008, MISRA released the C++ equivalent standard.  So the obvious question is, should I apply this to my software source code base?  In short, yes.  Maybe you don’t need ALL of the MISRA rules, but there are certainly some that are worth your time.

Examples range from the very simple checker rules sets that mostly fall into the coding style category:

MISRA C rule 19.1:  All #include directives in a file shall only be preceded by other preprocessor directives or comments.

MISRA C rule 2.2: You should only use /*…*/ style comments.

Down to more important issues (I hope everyone has the tools in place to find this):

MISRA C rule 9.1: Unintialized variables.

It really depends what you’re trying to accomplish.  Certain rules such as 9.1 are very important, while others can help you with portability or just serve to make your code more maintainable and less complex going forward.

Word of warning, taking an existing software code base and apply the entire MISRA rule set is guaranteed to throw many errors.  Take the zlib project, obviously not MISRA compliant, but to illustrate the impact of turning on all the MISRA rules, will throw over 5000+ issues.  That is an issue for every line of code…yeah that’s useful.  So be warned, don’t try to boil the ocean.  Start iteratively, even if that means only one rule at a time.

In a previous post I provided the top 5 C/C++ quality bugs that I that I see time and time again looking at customer code.  Time for the C# version:

1.    Null pointer exceptions from a method

1                  public class A {
2                      public A foo() {
3                          if (flag)
4                              return null;
5                          return new A();
6                      }
7
8                      public void var() {
9                          A a = foo();
10                         if (flag)
11                             a.foo();
12                     }
13
14                     private int flag;
15                 }

This is the most common issue I see.  In this example a warning is issued at line 11 for a possible null pointer exception.  Essentially there is a potential for a null value from the method foo().  I believe I see these issues more than any others  because of the inter-procedural context of this issue.  This example is quite simple, but where you can easily get lost is when that null value is coming from a long method call chain in multiple classes.

2.    Resource leaks

1  using System;
2  using System.IO;
3
4  namespace LeakExample
5  {
6      class Test
7      {
8          public String Run(String name)
9          {
10             StreamReader reader = new StreamReader(name);
11             String result = reader.ReadToEnd();
12             reader.Close();
13             return result;
14         }
15     }
16 }

I think for most of us this is pretty easy to see.   An object of ‘StreamReader’ type is allocated and its reference is assigned to the ‘reader’ member. If the call to ‘ReadToEnd’ throws an exception, control is transferred out of method ‘Run’, variable ‘reader’ goes out of scope, the object referenced by it becomes lost, but related resources are not disposed.  See my previous blog post on how some people miss this and what you need to do to fix this.

3.    Forward null pointer exception

1                  public class A {
2                      public void foo() {
3                          A a = new A();
4                          if (a == 0)
5                              if (flag)
6                                  a.foo();
7                      }
8                      private int flag;
9                  }

This is another example of a null pointer exception with a twist.  In this example the class data member ‘a’ is compared with 0 value at line 4, and therefore may still be expected to be null when it is dereferenced at line 6.

4.    Reverse null pointer exception

1                  public class A {
2                      public void foo() {
3                          A a = null;
4                          a.foo();
5                          if (a == null)
6                              a = new A();
7                      }
8                  }

Yes, another null pointer exception (getting a theme here?).  Same idea at #3 but in reverse order.  Here they dereference the data member ‘a’ at line 4 but later check for null at line 5.

5.    Empty catch clause

1  class FileHandler {
2      public void Open(String name) {
3          try {
4              // opening file ...
5          } catch (FileNotFoundException e) {   // defect - no statements in the 'catch' clause
6          }
7      }
8  }

Okay, so not exactly the big impact as the top 4, but I just had to mention it.  I’m always guaranteed to see some of these.  Granted they are maintainability issues more than anything else, but c’mon they are there for a purpose.
As promised, I did say that I would post the Java version soon.  It is next…

Just returned from ESC San Jose, where I spent a very enjoyable few days surrounded by the “real men” of the programming world. Forget your managed language environments, forget abstractions or object oriented fantasies of design, forget processes like Agile, these guys spend their days down at board level working in assembler and occasionally sticking their heads up into the rarified world of C (but only, you know, for stuff that doesn’t really matter…).

Hell, most of the time the hardware they’re programming is custom built just for that project, sans O/S because, you know, why would you want that crap to get in your way. One guy that stands out in the procession of awesomeness was describing his ASIC to me, asking if we could help with stack overflow problems, and launched into a necessarily abstracted description of the fact that their (classified) device didn’t really have a stack, actually, but it was kind of a well known address range that they normally treated like a stack, although not always because, you know, stuff sometimes gets in the way, so if he, like, stuck something in there that was too big, could we tell him?

God, I love these guys…

Now I began programming on boards in Z80 assembler, so trust me that I do actually know what the heck they’re doing and why, but over time I’ve followed what has felt like a fairly natural migration away from the kind of “if I want to light up that LED I have to store 0x2d in address ‘x’” programming to C, then C++, and more recently to Java and C#. Of them all, I think C++ is probably my favorite, simply because it’s low-level enough to be useful, and high-level enough to let me express myself without having to think too much about it. Frankly, in my opinion while good developers are good in any language, really good developers find their own way and then excel at it. So yes, I can probably program in any language given a few days of spin-up time, but frankly I’m too old and too cranky to get all fired up over the latest innovation of hiding-the-useful-stuff-from-me just so I can do it a bit faster.

Note that I’m not espousing any kind of intelligentsia-sponsored BS argument over the “value” of OO languages over procedural or vice versa (for more vitriol than typically fits on one page, check out this beauty from Torvalds…). And no, I don’t use STL so just shoot me, but it sucks so get over it. And if you get your rocks off over Python or Ruby or Haskell or whatever new lambda calculus-based micro language you’ve just stumbled over, have fun and get your job done, there’s enough of them for everybody, after all.

But don’t try to convert me. Proselytizing is always ugly, so just step away from the bong and let’s all be friends here. The Urban Dictionary nicely summarizes things:

The men who program in C++ are Real Men. The women who program in C++ are Real Men too.

Substitute the name of your favorite language in there in place of C++ and you’ve got the way most developers think about their own language of choice. How about you? Any favorites out there you’re willing to get boiled in the pot for?

Have just stumbled across the lamda module in boost (popular C++ general-purpose library known for extensive usage of templates and influence on C++ standard committee).

A quote:

The primary motivation for the BLL (Boost Lambda Library) is to provide flexible and convenient means to define unnamed function objects for STL algorithms …

for_each(a.begin(), a.end(), std::cout << _1 << ' ');

My first thought was: "Hmm ... a macro?" It appears it is not. The <code>_1 object is a lambda placeholder, and should be read as first parameter of lambda expression (a.k.a. unnamed function). In fact the std::cout << _1 << ' ' expression is automatically converted into a function-like object, that can be used with most STL algorithms (like for_each, find_if, etc.) So, instead of writing this (a traditional STL way): template <typename T> struct my_printer : public std::unary_function<void, T> {      void operator()(const T &x)      { std::cout << x << ‘ ‘; } }; // … for_each(a.begin(), a.end(), my_printer<my_element_type>());

You can use the above expression, and C++ compiler automatically creates anonymous class that represents an unnamed function. The trick is that all this "behind-the-scene" work is expressed in terms of C++ templates and heavily relies on automatic type inference, and operator overloading. Essentially the module has to overload every possible C++ operator that can be applied to the lambda placeholder, "delay" the evaluation of expression and "wrap" the computation into a callable object.

This approach apparently simulates Lisp lambda expressions (hence the name of the module) and Smalltalk/Ruby code blocks:

a do: [ :⁣x | Transcript show: x; show: ' ' ]

a.each { |x| print x, " " }

(for-each (lambda (x) (display x) (display " ")) a)

Lambda expressions and code blocks are essential part of these languages and one of the things that make them consistent and fun to use. Now, this library is trying to adopt this concept into C++.

Pretty cool, but the following limitations lead me to think that this C++ implementation of lambda expressions is far from complete:

• Boost lambda expressions are not true closures (you can not refer to "non-local" data from the block)
• Some operators (most notably "." and assignment) can not be overloaded this way, so i = _1 and _1.my_field does not work and requires some extra C++ tricks
• Can not use statements in this kind of code blocks, works only with expressions
• If you make a simple mistake in this kind of lambda-expression (or change some related interface), the C++ compiler will gladly present you with a pile of human-unreadable error messages with about a dozen template instantiations with names that do not fit a line of text (no matter how wide your LCD panel is), using each other ... that's a common problem of all non-trivial template libraries

After all, this demonstrates that C++ templates and type inference are indeed powerful concepts, but still not powerful enough to redefine/extend the language in consistent way.

Another problem with this kind of smart C++ tricks is that it creates an illusion of simplicity. As always with C++ - you can not rely on this simplicity, unless you know the details of what's under the hood. If you dare to ignore implementation details you risk losing control over your own code one day.

I’m picking up the theme of the CWE Top 25 today (see posts below for more detail on the list itself, or check out this blog posting for a more exhaustive description) as we run into what is described as CWE-404 all the time in managed code environments.

Although most C/C++ developers recognize explicit resource management as an issue, I’ve recently found out talking to some of our customers that they are totally unaware of the need to worry about such things in Java and especially C#. I even had one customer tell me in the context of C# that the CLR will “take care” of the issue. While it’s perhaps true that eventually the Finalize() method might take care of many resources, professional developers really should take the utmost care in dealing with precious unmanaged resources like file handles, graphics handles, or database connections.

A simple but surprisingly common example in C# illustrates the point:

using System;
using System.IO;

class Blah
{
static void Main()
{
StreamReader r = null;
r = File.OpenText (“blah.txt”);
if (r.EndOfStream) return;
Console.WriteLine (r.ReadToEnd());
}
}

The StreamReader class used here encapsulates an unmanaged resource, the underlying file handle that the O/S allocates to the CLR during the call to OpenText(). As you can see, that unmanaged resource is never released back to the O/S (until such time as the application terminates, of course).

A simple statement:

r.Close();

in a finally block would clean it up.  Calling Close directly is okay but it is crucial to make sure you put that in the finally block.  The most common resource leaks that I see static analysis tools find are the ones where you see a developer has been smart enough to dispose of his resource but there is another path (such as an exception that can be thrown on a method) where the resource is not disposed.

Another easier way to dispose of the resource is to apply the “using” statement, which calls Dispose on an IDisposable object automatically for you. This code:

using (Streamreader r = File.OpenText (“blah.txt”))
{
…
}

is the same as writing:

Streamreader r = File.OpenText (“blah.txt”);
try
{
…
}

finally
{
if (r != null)
((IDisposable)r).Dispose();

}

So make sure you know that you need to dispose of certain resources.  In fairness, these can be hard issues to detect, particularly in an inter-procedural context, but good regimented use of code reviews, coupled with a good static analyzer should get you well on your way.

It’s kind of bizarre, but in my pre-Klocwork experience of running ISV development groups, from small teams to global enterprises, it never struck me as wrong that we would routinely ship software containing critical bugs. We knew we were doing it. We knew, on some abstract underground never-to-be-admitted layer of our deepest darkest souls, that this was a “bad thing.”

But mostly, we knew that when somebody found a bug we could just send them a patch.

And what’s more, we knew that customers expected this behavior. We got requests to “send us a patch quickly, this is causing me {insert unpleasant business scenario here}.” We had customers telling us that we were a great company to deal with, because we responded to patch requests quickly.

We weren’t the bad kids on the block, we were right up there with the upstanding corporate citizens of the software world!

Why are software companies allowed, perhaps even expected, to mess up on this scale? If we were engineers, we’d be sued. If we were doctors, we’d be in court before you could say something snappy and relevant like “most software sucks.” But for ISV developers, hey, it’s just business.

Talk to developers in the embedded space, or mil/aero, or telecoms, or a bunch of other places where this approach to business isn’t acceptable and it’s like talking to engineers. They understand what their tolerances are, they understand what it takes to make quality software, and they fundamentally understand on a basic level what happens to them and their company if they get it wrong. Inventory turnover is one thing, killing people is something else.

So is it just that ISV software is unimportant? That ISV software won’t ever be put in a situation where it could be life-threatening (or life-enhancing), so it doesn’t matter if it crashes all the time?

Obviously that’s not the case. Software created by ISVs is used all over the world, in all manner of situations, some dire, some not, but at the end of the day, in every situation, there’s a name on that software.

Your name.