“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 testing procedures are sufficient, stating that the plaintiffs shouldn’t be forced to rely on Ford’s determination of what information is…

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 put what’s called ‘spaghetti’ in their code” 😉

There should be a MISRA Rule that prohibits this 😉 – Clayton

The MISRA-C/C++…

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 and mis-grammer become blantently obvious. Even with auto tools. Sigh.

So in the meantime (between publishings), something falls on…

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 rooted from more than just a few grains of truth: “What does MISRA stand for?”. Actually this is not as…

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 approaching a problem, let’s say at the “analysis phase”,  this sort of contemplation is exactly what is called for.  Its the 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, leaving that for later discussion. Well, the student started a new thread, keeping her status as a Top Contributor in the LinkedIn…

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 = g() | (f() + g()); //bitwise or
}
int f() {
if (x == 0)
...

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” field, a report of a bug existing is often based on an ever moving threshold of its importance based on…

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. However, today I ran into a situation that totally flummoxed me. I have some definitions:

#define Kret 73u
 #define maxParams 10u
 #define ret1_value...

Continue reading →

Run time checks straw men and overhead 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 table discussions where a few break off into corners talking about their mutual interests in rock climbing or their mother’s having…

Continue reading →

Run time checks straw men and overhead vs. MISRA-C (part I)

As I mentioned in this post, there are many conversations I find myself contributing to, mostly about software engineering systems the right way. For C, this means rigorous code inspection prefaced by automatic enforcement of C subsetting standard, such as MISRA-C 2012 which focuses on prevention first, cure second. So here’s my first step on a mission to resurrect the gist of these conversations in article form.

Some upfront conventions on this:

  • Excerpts of my posts and responses taken from these discussions are (no anonymity of course) with the Veriloud quote sidebar..
  • Excerpts of posts and responses from other authors are in quoted block form with LinkedIn…

Continue reading →

On Being Very Loud and Clear with Systems Software Quality

Veriloud is about software verification beyond testing.  Actually before, during, above and beyond.

Testing is only half the story with full verification. 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 develop in our lifetime.  So, I will very loudly be speaking my mind on this, as it is the biggest technology threat to mankind, ever.

Yes, I know, you don’t read a lot about this so that’s where Veriloud comes in. To begin with, let’s step back and explain why this started.  I’m an active participant in a Linkedin group called MISRA-C & C++,…

Continue reading →