The lawyers are coming!

12/6/2009 12:08 PM EST

This will not be fixed with coding standards, but will be fixed when the embedded community drops the use of the C language. Every example of abysmal code you gave was in C or C++, so the problem must be in the language. Has the author ever been hired as an expert witness in a case involving Java or even Assembly? When three experts look at a single line of C code and can not agree on how to make it safe, the use of coding standards will not make that line of code any safer. If you are using a language which requires interpretation of its function on a single line of code, you are using an abysmal language.

12/6/2009 3:44 PM EST

When correctly implemented, "best practices" are the most important element in getting good software! But in the real world there will always be pressures. And when "push comes to shove" these pressures enviably "overrule" the "best practices".

Here are a few examples from "high quality" "big $" environments.

Code being dynamically created and executed from the registers. The really crazy part was that there was a very good reason for this code. The sad part was that there was no documentation for this code even in the source code. This was an (all too common) case of an inflexible "best practices" turning a "less than best practice" into a "very dangerous practice".

Code that would only declare an equipment failure when a section of test code failed more times that it was executed. This was found by a number of users when the life cycle of the associated cable wraps was significantly less than anticipated. Apparently individual multi-million dollar systems were being accepted ($$$) based on an extensive and impressive test of the overall system; and this sub-test was just an "insignificant test" in one of the sub-systems. The worst part was that system integrator had the ability to independently patch the software without changing the version identification. No doubt some key managers received a lot of credit and probably bonuses while years later the problem was attributed to the software.

Code that stored data in memory locations on the "wrong" side of the stack-pointer. That’s right; data was being stored both above and below the memory address in the stack pointer. This problem was found after the extensive and expensive Independent Verification and Validation (IV&V) of the software, and after several years of real-world use. It was only found when an interrupt used to replay the software execution interrupted the offending code and automatically clobbered the "wrong" side of the stack. The executable machine code is the only safe place to determine if you are doing the IV&V on "all" the code.

I am sure that we can come up with "best practices" solutions for all these problems. And then the people that are looking for the quick way to the "top" (and there is a lot of them) will find other ways around the "best practices".

Until the "best practices" connect the "real-world" to the programmer and provide "real" feedback, the latest and greatest "best practices" will be little more that talk and extra paper work!

12/7/2009 4:36 AM EST

As a dishwasher/kitchen help in previous life, I learned that a sharpest knife is the best tool. C language is just that, a sharp knife. When you talk about bugs, it's always people or companies causing it. We don't blame English language for being too ambiguous/vague; we blame the speaker(s) or writer(s). And luckily, Java is not used in engine-transmission controls, anti-lock brakes or air bags (It's C). It's also easier to hide bugs in safety critical industries such as military or medical (It's all confidential/secret until a successful lawsuit after many deaths). Sometimes, even co-workers are not supposed to know your code (code review?).

Patrick

12/7/2009 8:27 AM EST

Patrick,

Good point. But I disagree about English. It's notoriously imprecise. It's like C - a tiny change greatly alters the meaning.

Consider:

Eats, shoots, and leaves.

Vs

Eats shoots and leaves. (Think panda bears)

One reason we have so many problems with software is the code is derived from an imprecise English-language specification. I suppose the alternative is formal methods, but they probably won't make many inroads in the near future.

Jack

12/8/2009 2:46 PM EST

Jack, I don't think Patrick is claiming that English is a precise language. Read again:

We don't blame English language for being too ambiguous/vague; we blame the speaker(s) or writer(s).

I believe he's stating just the opposite, namely English is ambiguous and vague, but even so, it's the responsibility of people using the language to be unambiguous and clear despite the shortcomings of the language.

12/17/2009 12:54 AM EST

Lucky for us, we have young and inexperienced - but CHEAP - engineers in other countries willing to work for a fraction of the salary an engr in the US would earn. We can simply blame the global economy and let the lawyers try to sue India or China.

12/18/2009 10:07 AM EST

There is quite a lot of scientific research about accidents in safety-critical systems that were caused by software, like this article posted on this site:

http://www.embedded.com/columns/technicalinsights/220900315

The largest culprits are not the choise of language, or not even classic software bugs, but errors in requirements, specification and failure to forsee every aspect of the environment the product was to be used in, or failure to adapt the program to users / human beings.

Based on the above, it is just laughable to claim that the C/C++ language would be the main cause of accidents. If we want to point fingers at an unsafe language it should be assembler, because it lacks any formal standard, it lacks encapsulation, it gives the programmer direct access to the stack pointer and registers etc etc.

And naturally there will be no trials involvning Java, since nobody is using Java in safety-critical applications. Java is an excellent language in theory, but unfortunately the real world implementations of it are too slow to be used in anything but web/toys/fluff applications.

Still, it all boils down to this: incompetent programmers will produce bugs no matter language.

2/8/2010 9:00 AM EST

Retired Aerospace President
Since the old MIL-STD-2167 decades ago to the current DO-178B standard, aerospace software has been able to maintain very decent record. 100% quality is probably unachievable, but prevention of catastrophic or unsafe results of a software failure, in combination with hardware failure analyses, is. I don't buy the argument that the adherence to these engineering methods is not economically feasible. Their principles can be implemented at much reduced cost (compared to aerospace) by reducing the extent of formal reviews and documentation.
In the end, the piper will have to be paid. Either at the front end by higher engineering cost or at the end by losing customers and feeding legal profession.

3/28/2011 11:21 AM EDT

You provide a link to your presentation: http://bit.ly/badcode . It translates to http://embeddedgurus.com/barr-code/files/BadCode.pdf which unfortunately does not exist.
I looked briefly on your website but couldn't find the PDF. Could you please check and make it available?

3/28/2011 1:11 PM EDT

The world refers to diffent fixed methods of creating instruction sets for processors as "languages" and gives them names much like we name spoken languages. We must not believe these coding tools to really be languages or we will expect to much from them. Try the phrase 'the first one won one one dollar bill'. It must be fully read or heard then placed in context as to both the listeners experience and the environment in which it was presented then at least in part reviewed again before understanding emerges. Understanding is not available from only the phrase itself and that is the wonder and delight of language. Coding does not bring that broad use of context and environment to it's application. It must be complete and closed within every line of code. to accomplish good code review the writer and/or reviewer must "dumb" their thinking to avoid even knowing what the code must do but only considering what that particular line must do. The difference is subtle but upon study becomes a common possible answer to many coding errors. What the line must do is a quite separate but also necessary part of such a review.