Software Integrity

 

Meet Auntie MISRA

Meet Auntie MISRA: Establishing an enviable industry reputation
Seems we all have one: that distant aunt. You know the one I’m talking about. Always dressed to the nines. Always perfectly coiffured. Every detail just so. And that tiny Jack Russell that did tricks on command, never yapped (unless told to “speak”), and was always at her side, springing up to her lap when she pulled out a little Burberry scarf for it to rest on.

Her kids – your cousins – are miniatures of her. Hair combed. Shirts always tucked in. Gig lines straight. Did their homework without being asked. Always got great grades. The whole ball of wax.

Yeah. You hated them.

And her.

And her little dog, too.

After all, who could put up with her and her fussiness?

Thing is, you secretly admired how easy everything seemed for her and your cousins. They were unflappable, always prepared for everything, and they moved in different – rather lofty – circles.

Rumor is, this wasn’t always so. Seems that Auntie MISRA had rather humble beginnings. What gives?

Fussy, fussy, fussy!

Ah, dear old auntie. It’s easy to have the same opinion of MISRA. It is, after all, very fussy – even maddeningly so – about seeming minutia.

But MISRA was born of the fact that C and C++ have some rough edges that present reliability risks, and the last thing the automotive industry wanted was accidents caused by unreliable software. So, the MISRA standards try to winnow away those parts of the language that – either by specification or by experience – are known to allow bad things to happen. Though born in the automotive industry, it has gained acceptance in many other markets, too: aerospace, biomedical, communication, financial; any place where failing code would be catastrophic, expensive, or at least undesirable.

There’s that old saying that C gives you enough rope to hang yourself with. It is, after all, a very powerful language, with very little getting between you and the hardware you’re targeting. For the most part, it’s one notch up from writing bare assembly. Tell it to make the hardware do something and the language will pretty much oblige. The onus is on you to not make it do the wrong thing. It will not stop you from tying the proverbial knot, placing the loop around your neck, and….

Solving the behavior problem.

With protecting you from yourself not being a design consideration, the language also has a number of undefined behaviors. Some are subtle, some are counter-intuitive. Many are historical.

What happens, for example, when you right-shift a negative number? Did you know that this is implementation-defined?  In other words, your current compiler may exhibit desired behavior, but if you ever use another compiler, it does not need to behave the same way. Counting on one behavior or the other is unreliable.

So naturally, fussy ol’ Auntie MISRA says “you really mustn’t do that!”

Sure, you can thrust your hands in your pockets, saying “yeah, what-ever” as you shamble away, resolving to continue to do what works for you. It works, after all. Why “fix” working code?

Maybe so. But you’re consigning yourself to a very narrow future by doing so. Want to move in your aunt’s circles? Tucking in your shirt won’t kill you. Want to win a contract that puts your product on that new hardware platform? Developing coding habits that won’t cause your code to trip on your – or on any other – compiler’s quirks won’t either.

It ain’t ‘broke,’ but fix it anyway.

Way back when, programs were smaller, and in far fewer places. If some code went splat, big deal. Just start it up again. We could tolerate some level of unreliability in software, mostly because we weren’t so reliant on it.

Nowadays, software is far more complex, far more pervasive, and we have come to depend on it in our day-to-day lives. So, crashing software can have fairly significant consequences, even if we’re not talking about automotive braking systems or pacemakers where failure can really ruin somebody’s day. A graphics card’s driver causing a kernel panic may not have life-or-death consequences, but won’t be making users happy.

Reliability matters. Pretty much everywhere these days.

So, listen to your auntie. Tuck in your shirt. Comb your hair.

You can write better, more reliable code. It’s just a matter of picking up the right habits, and sticking with them.

That’s all Auntie MISRA does. Look what she made of herself!

Achieve MISRA compliance reliability.

Pick up the right habits