The Ten Commandments for C Programmers
News from Embedded Systems Conference 2009, in San Jose: “Accomplished for the first time in a commercially available phone, Chicago-based Open Kernel Labs’s mobile virtualisation solution enabled Linux and an RTOS to run side by side on a single ARM processor.”
The firm produces the ‘virtualisation’ software: code which controls access to hardware resources, allowing both the RTOS and Linux to run separately as though there were the only operating system on the processor. Such software is also known as a hypervisor.
Read the full article: OKL hypervisor runs Linux and RTOS on Motorola’s QA4
Many years ago Henry Spencer wrote down what he considered to be ten of the most fundamental rules all C programmers should follow. Reading them now they seem almost funny (anyone still program for a VAX?). But for an embedded engineer they still ring true.
The Ten Commandments for C Programmers
- Thou shalt run
lintfrequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine.
- Thou shalt not follow the
NULLpointer, for chaos and madness await thee at its end.
- Thou shalt cast all function arguments to the expected type if they are not of that type already, even when thou art convinced that this is unnecessary, lest they take cruel vengeance upon thee when thou least expect it.
- If thy header files fail to declare the return types of thy library functions, thou shalt declare them thyself with the most meticulous care, lest grievous harm befall thy program.
- Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest “foo” someone someday shall type “supercalifragilisticexpialidocious”.
- If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest “it cannot happen to me”, the gods shall surely punish thee for thy arrogance.
- Thou shalt study thy libraries and strive not to re-invent them without cause, that thy code may be short and readable and thy days pleasant and productive.
- Thou shalt make thy program’s purpose and structure clear to thy fellow man by using the One True Brace Style, even if thou likest it not, for thy creativity is better used in solving problems than in creating beautiful new impediments to understanding.
- Thy external identifiers shall be unique in the first six characters, though this harsh discipline be irksome and the years of its necessity stretch before thee seemingly without end, lest thou tear thy hair out and go mad on that fateful day when thou desirest to make thy program run on an old system.
- Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that “All the world’s a VAX”, and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short
As an embedded engineer I still believe these are good rules to follow.
I don’t use
lint much any more, but I do ensure that all warnings are enabled from my compiler and I read them all. Why? Because I know I make typos. I know I make mistakes from time to time and I really appreciate the help the compiler can give me. But the compiler is not perfect so I also recommend code reviews by other engineers. A fresh pair of eyes can often spot something neither you nor the compiler noticed.
Do you check all your array indexes? Make sure strings will fit into allocated buffers? These are sources not only of potentially annoying bugs but also security vulnerabilities.
Do you test the return codes from all functions that may return them? Yes? Good, but do you test the branches of code that should handle those errors when they occur? It is never as easy as you think it will be. When you are writing a test harness (you do write those don’t you?) you should also be using a code coverage tool to make sure you tested what you thought you did.
Make good use of the libraries already available. Not only are there already many excellent, high quality libraries available for C but for other languages too. If you are a C++ programmer then don’t forget Boost or Qt (now available under an LGPL license) too.
Whilst the world is not a VAX any more, neither is it an x86. Consider that your code may run on a PowerPC, ARM, MIPS or any of the many other architectures supported by Linux. Some processors are big endian, others little. Some 32-bit and others 64. Most are single core but increasingly they are multi-core.
Ignore these commandments at your peril.