Thank you for sharing your knowledge and experience.

I read all 12 tips and learnt a lot!

So switch (x)
{
case 0:Code_Zero(); break;
case 1:Code_One(); break;
case 2:Code_Two(); break;
..
}

.. gets compiled as:

R0 = (x);
JEQ CODE_ZERO();
dec(R0);
JEQ CODE_ONE();
dec(R0);
JEQ CODE_TWO();
etc…

It’s an optimization I’ve seen for switch statements but not for the equivalent ‘if’ structure.

Like the MSP430 compiler used in the Code Composer Studio has an intrinsic built in (_never_executed()) which tells the compiler, that the default case is never executed, and thus the variable in the switch statement has to be one of the cases handled above. (see TI document SLAU132) The compiler is then able to generate more efficient code.

This puts some pressure on the programmer of course, he now has to ensure throughout the code, that the variable always maintains valid values.

And naturally, many defensive programming methods will be very resource-consuming. I’d be wary of taking things to the extreme, as preached by standards like 60730 or its evil brother 61508, that encourage crazy practices like “walking pattern” memory tests, where you in runtime move a bit pattern through the whole RAM to check for corrupt cells. I’m quite sure that such algorithms will not only be incredible slow, they will be introduce notable hazards and needless complexity. I don’t think programmers should fiddle around with such, it should be implemented in hardware. Such efforts are also currently being made by MCU manufacturers.

As a sidenote: after spending considerable time with standards like 61508 and ISO 13849, I always come to the conclusion it they are the work of bureaucrat madmen, and that the encouraged practices aren’t based on scientific proof, nor that they have any relevance to safety nor engineering.

To your second point concerning defensive programming. Let’s assume that between masking the DIP switch value and testing it, some form of corruption occurs, such that it is no longer range limited to 0-15. In this case, a default statement may provide a modicum of protection. I say ‘may’ because if the compiler chooses to implement the switch statement as a jump table, then it will probably emit code that consists of:

Check that the value is less than 16
If it is, index into the jump table
Else jump to the default handler

Of course, this begs the question, what happens if corruption occurs between the check and the index into the jump table?

Notwithstanding this, I think your comment illustrates that there is a natural tension between efficient programming and defensive programming. Efficiency is typically about doing just enough to get the job done. Defensive programming is about trying to ensure that the real world doesn’t intrude and cause your system to crash. I use defensive programming by default (if you would pardon the pun) and efficient programming when I have to. Incidentally I wrote a posting a few years ago about another defensive issue – IEC60730. I’d be interested on your comments on that.

The question is, how can you know? The reason MISRA enforces “default”, as well as “else” after every “if-else if”, is for one purpose, and that is defensive programming. If your memory gets corrupted by bugs or by hardware-related problems (EMI memory corruption, broken ADCs, brownout etc etc), a default statement can catch those and you can gracefully terminate/reset the program, instead of running haywire.

The term defensive programming is typically completely alien to pure software academics. There is just no way they can get in their head that the program may be exposed to the real world outside their desktop, and that an algorithm that is perfect in theory may not be perfect in practice. An -engineer- should however understand and practice defensive programming, especially in safety-critical systems.

What I like most about this blog is not necessarily the advice given but the fact that it makes you think twice about how you do things and how you could improve.

I thinks that’s one of the best things anyone has ever said about this blog Daryl – so thank you. Developing this idea a little bit, while there are indeed some fundamental truths in the embedded world, the space is in general so large and diverse that almost any advice can be shown to be poor in certain circumstances. Thus read, learn, but above all think!