Is MISRA-C applicable to Linux applications

Question

I understand that MISRA-C standards are intended for embedded firmware. When embedded Linux is your product platform, can/should your embedded applications be developed to be MISRA-C compliant? Has anyone ever considered such an exercise?

My general sense is that you must first understand all the 'rules' and then apply them in your design/coding phase. There may be instances like system calls (pthread_create) and void* that need to be forced into compliance - producing ugly looking code.

Answer 1

While MISRA-C was originally created as a standard just for automotive and safety-critical applications, this is no longer true. Nowadays MISRA-C is more of a general standard that can be used for any C programs where bugs, crashes and portability issues are not desired.

You need to ask yourself why you are using MISRA-C. Is it because you wish to use it as a coding standard to get rid of bugs, or because the application is of a mission-critical nature?

For the Linux case, the main issue will be if you'll just have your own code MISRA compliant, or if you will demand that this is true for all libraries included as well. And there is just no way you'll make the Linux kernel + libraries MISRA compliant, you'd have to rewrite Linux from scratch.

This makes Linux unsuitable for mission-critical software. But if your program is not of a mission-critical nature, you should be able to use Linux. You might have to write a number of standing deviations from MISRA-C in advance, for things that you can tell will cause problems.

Answer 2

In a word: No.

MISRA does provide some good guidelines, but you'd be better off just cherry picking rules to which you want to adhere (assuming you have automated checking in your build / static analysis).

Skimming through MISRA-2004 stuff, here are some problem areas.

Having all your libraries be MISRA compliant is, in itself, MISRA rule.

Rules on goto, continue and break, function returns, and pointer arithmetic are violated in literally billions of lines of both kernel and userspace code, so good luck getting your libraries (or kernel) under compliance.

Pointer casting rules will be impossible to follow if using sockets, among other common APIs.

MISRA-2004 11.2 Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void.

2004-20.x sections ban <errno.h>, <stdio.h>, <time.h> and <signal.h>. Banning signals and error checking promotes BAD Linux programming if you're writing long-running, robust services.

And no dynamic memory allocation is a rule in there somewhere.

I know MISRA has rules that allow you to violate rules if you document them (is this true for required or just advisory???), but you'll document soooo many exceptions that it's really sort of pointless.

All that said, if you have a customer insisting on MISRA compliance (which is the only reason I've ever seen it used), you could probably document all your rule violations and make some hand-wavy attempt to call yourself MISRA compliant. So there might be a business case for pretending to be MISRA compliant on Linux, but I see little to no technical advantage in it.

I'm afraid if you want to be truly compliant AND need a heavyweight/full-featured OS you're better off forking out the dough for QNX, GHS Integrity, VxWorks, etc.