Some time ago, I wrote about well-known trick for a two-value exchange using no intermediate variables. It’s a fun party-trick, but unless you’re working with an unusually constrained embedded project, it’s unlikely that you would ever really need to use it. On the other hand, hidden within that little trick is some real memory-conserving magic.
I’ve been writing software in C since 1991. While that was shortly after the ratification of the C89/90 standard, it took at least a few years for most compilers to catch up. So my formative years in C were spent developing code for compilers that weren’t yet standards conformant. Certain features were hit and miss. Since much of my development work involves C, I try to keep up with new developments. I freely admit that I don’t know it all; and every few years someone teaches me a new trick or hack that makes life just a little bit easier. Recently, I found a major gap in my understanding of one important aspect of the language.
Not so very long ago, I was given an assignment to perform a forensic analysis on a piece of firmware. It seems that my client’s device had a rather spectacular failure which endangered many lives. The job was critical, but this was new territory for me.
As I’ve said before, MC/DC analysis is the bane of Level-A development under DO-178B. It is not well understood, either by developers or by verification engineers. Automated analysis tools will perform the analysis, but that may not occur until verification has begun. Fixes at this stage are far less desirable than avoiding issues in the first place. So how do we ensure that MC/DC issues do not occur in the first place?
Like many veteran software developers, I am sold on the value of defensive programming. It seems that no matter how thorough the requirements, nor how good the design, things can go wrong; and I’d like my code to be able to handle it. So imagine my surprise when no less than a DER provided me with a perfectly valid and well-reasoned argument to discard defensive programming techniques altogether.
In 1968, Edsger Dijkstra published the paper that put him on the map permanently in the minds of most of the software development community. While he made a number of very important contributions to computer science during his lifetime; I believe that “Go To Statement Considered Harmful” has spawned what has become perhaps the most enduring and pervasive religion in the annals of computing history. In my two-plus decades in the industry, I’ve seen only one coding standard which did not entirely prohibit the presence of the goto statement; and even that one that allowed it in one limited circumstance.
When I originally titled this article, I had no idea just how appropriate it would turn out to be. Thanks to a series of events that has occurred over the past few weeks, this article has become a 3-time, self-referential do-over. Self-fulfilling prophecy, or simply an application of Murphy’s law?
