Embedded Muse 52 Copyright 2000 TGG October 4, 2000

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- MISRA Review
- Thought for the Week
- About The Embedded Muse

MISRA Review

In just a few weeks the 70 page bound booklet arrived. It’s emphatically NOT a software standard; rather, the authors define safe ways to use some C constructs and identify others that must be avoided. Use these guidelines in concert with a real standard, one that defines coding styles, commenting conventions, and the like (you’re welcome to download the one I use from https://www.ganssle.com/misc/fsm.doc).

While C is indeed a very powerful language, it should come with a warning label: “danger: experts only”. It’s so easy to create programs that leak memory, run pointers wildly all over memory, or create other difficult-to-find havoc.

Quite a few of the MISRA rules make tremendous sense: don’t redefine reserved words and standard library function names. Document and explain all uses of #pragma. When a function may return an error, always test for that error. Functions should have a single exit point.

Some are interesting: never use recursion. Keep pointer indirection to no more than two levels.

A couple are hard but possibly quite valuable: check every value passed to every library routine. Avoid many common library functions.

Other are trivial: only use characters defined by the ISO C standard. Don’t nest comments. Write code conforming to ANSI C. Don’t confuse logical and bitwise operators. Don’t have unreachable code.

Some of the requirements I find disturbing. For instance, rule 118 prohibits the use of dynamic memory allocation. Not a bad idea, due to problems associated with fragmentation. But there are alternatives to malloc/free that still give us the benefits of dynamic memory allocation without the pitfalls. More problematic, this rule tells us not to use library functions which employ dynamic memory, specifically mentioning string.h. This seems awfully restrictive to me… I sure don’t want to write my own string handlers… and further, how is one to identify the suspect libraries?

Rule 122 prohibits the use of setjmp and longjmp. These are worse than gotos, of course, in that they let us branch to specific memory addresses. Yet in a few cases longjmp is almost unavoidable.

I think there’s much value to the document, but as a stand-alone set of rules it’s incomplete. Better, incorporate the rules into your in-house software standard. It’s just too hard to conform to two sets of rules living in two different documents.

If MISRA published the rules on-line, they’d be more accessible to the embedded community, hopefully improving the quality of code everywhere. Without such an electronic copy, I doubt if many will ever incorporate these rules into their own standards.

Thought for the Week

In the 90s:
Recruiter: "Tell me all the options used by /bin/ls"
Candidate: "BSD options or System V?"
Recruiter: "You got the job!"

In the 00s:
Candidate: "Tell me all the options"
Recruiter: "20000, 1 year vesting, $1 strike price, IPO next month"
Candidate: "I'll take the job!"