Death To C – Long Live MISRA-C (part 1)

Every once in awhile someone takes notice of the traps and pitfalls in the world’s most popular and powerful programming systems language and ring the alarm bells.  That language would be C. Here’s the latest banter: Death To C (and C++ too)

It is deja vu all over again.  The premise is “C is bad” and the main point is a call for “a better language”, in this case “Rust“.  We’ve seen it with “D”, we’ve seen it with “Go”, we’ve seen…

Continue reading →

“Source Code is Relevant” – Test, but Verify

Earlier this month, an interesting decision was made regarding yet another lawsuit alleging Big Bowls of Spaghetti Code in a Car.      This time a Ford, from Ford Must Submit Source Code In Sudden Unintended Acceleration Case:

Ford argued against turning over source code from a technical stance, saying it already turned over relevant engineering documents and that the programming and algorithms forming the “nerve center” of its vehicles is impervious to outside influences. The judge disagreed that the documents Ford provided detailing the system’s design and…

Continue reading →

The Missing MISRA-C Rule…

Just some more proof I like to stir the pot in other forums, like this discussion I began in the Linkedin MISRA-C/C++ group. “The Missing MISRA-C Rule…”

I’ve been meaning to write an article that looks in depth at the expert testimony in the Toyota Unintended Acceleration and the Big Bowl of “Spaghetti” Code case, where the verdict in October 2013, I believe, was a game changer in software and one that will take us a while to realize.

They actually…

Continue reading →

Verifying what you write

I have three articles that I have written and just dying to hit the “publish” button on.  But I can’t, they are not ready, like software, an engineer has to know when is when, and when is not.  I don’t have a formal human review staff, I wish I did, I am sure I would be much more productive. As it is, I have to “deskcheck” very carefully. Even then, after hitting that “publish” button, I see through other’s eyes too late, and my myriad of typos…

Continue reading →

What does MISRA stand for?

A simple MISRA definition: “stands for best coding standards and practices in C/C++ software engineering”.

On the great internet of discussion forums, presentations and articles pertaining to C/C++ and embedded systems development, I see oft-repeated misunderstandings about MISRA. Myths if you will, some of which had, or never had, more than just a few grains of truth in them and certainly today in the era of MISRA-C:2012 needs to be countered.

I’ll tackle these myths in a future post, but let me tackle one misunderstanding about the MISRA definition that is…

Continue reading →

Dealing with the Unpredictable and how MISRA helps – Part II

continued from Part I

Dealing with the Unknown Reasonably

In software engineering, decisions cannot always be purely rational, based soley on logic and facts . Its discomforting, but that’s the way it is.  Just as an honest Doctor cannot always have all the answers upfront when you first walk into his office or take a first series of tests:

 

SomeThingsWeNeverKnow

 

In politics a person can receive the “Foot in the Mouth” reward talking in such a manner (deservedly so if such a statement is made after simplistic solutions had been tried and failed).

However, when first…

Continue reading →

Dealing with the Unpredictable and how MISRA helps – Part I

In my last article Role of sequence points not being the point – and how MISRA helps I talked about a student’s question regarding code that contained “Unspecified Behavior”. In my answer I explained:

your multiple choice question has nothing to do with sequence points. It has nothing to do with “Undefined behavior” either. I should add that it is not “Implementation-Specific behavior”. It is a demonstration of “Unspecified behavior”. Each of these phrases have distinct meanings.

I intentionally left out the definitions of these types of unpredictable behavior,…

Continue reading →

Order of evaluation and how MISRA helps

This article is about tangental discussions and how the C language can get even the most seasoned engineers off centered, and how using a good MISRA-C tool can help get us back on point.

I joined this discussion a little bit late in the LinkedIn “Embedded C Programming” group:
“Role of sequence points in deciding the value of the variables”:

I came across this question in a MCQ

int x = 0;
int main() {
int i = (f() + g()) | g(); //bitwise or
int j...

Continue reading →

Soundy is the new Truthiness (when not MISRA-C 2012)

Static Code Analysis (SCA) technology has many flavors, and words can take on different nuances even though they have a specific meaning within mathematics for describing logical properties. SCA that enforces MISRA-C 2012 and properties of source code itself are an exception. This is because analysis of source code can only infer what the implementation will be and conclusions about behavior are often based on assumptions and statistically based heuristics. Connotations of these terms, such as “false negative”, can even become idiomatic. For example, in the “bug-hunting”…

Continue reading →

An example why we need good tools

MISRA-C is only as good as the tools that enforce it and the activities of code inspection employed. Both go hand in hand as the ability of the tool to save developer review time as opposed to wasting time, is critical in making rigorous manual review practical.

This just posted on a Friday evening to the MISRA-C/C++ LinkedIn group:

I have been using MISRA 2004 for my later uC projects, and, for the most part, have understood the reasoning behind the rules….

Continue reading →

Runtime Checking & Testing vs. MISRA-C (Part II)

Continuation of discussion on run-time checking, or lack thereof in C and my advocacy of MISRA-C prevention being a key past of any solution.

Continued from Part I.

By my last count this thread was up to 237 responses. I am beginning to think  this idea of summarizing discussion thread conversations may have value.  The Signal to Noise ratio on these things can get pretty high as people meander into small talk.  Its like face-to-face round…

Continue reading →

Runtime Checking & Testing vs. MISRA-C (part I)

NotAJoke2

As I mentioned in my introductory post, there are many conversations I find myself contributing to, mostly about software engineering for critical systems.

I will start with a thread I just posted a response to in the Linkedin Plain Old C Programming group.

The Original Topic (OP) was “Run time checks, straw men and overhead“, where the Original Poster (OP) lamented about the C language’s lack…

Continue reading →

On Being Very Loud and Clear with Systems Software Quality

Veriloud is about software verification before, during, above and beyond testing. There is much more to this, but for now let me introduce and explain the Veriloud blog.

I continually find myself engrossed in conversations and debates fighting the belief that testing by itself is the optimal path towards achieving systems software quality. But testing is only half the story. In fact testing is never enough.  Especially if the system is developed with a programming language called C, which is pretty much the majority of systems developed and will be…

Continue reading →