Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Review Suggested Edit

You can't approve or reject suggested edits because you haven't yet earned the Edit Posts ability.

It is true that MISRA-C has a heavy focus on embedded system, though it has become somewhat more generic over time. The MISRA guidelines have been changed and improved several times over the years (in 1998, 2004 and 2012 + numerous TC and addendum/amendments). They are now definitely general enough to cover all embedded C programming, even outside automotive and safety-critical.
In general, MISRA-C is a good document for any form of C programming - I would recommend every C programmer to read it as learning material, even if not implementing it. The majority of the rules are sound and backed by sources and expertise.
There are however a couple of things that may make MISRA-C burdensome in PC/desktop ("hosted") systems programming:
- No heap allocation.
MISRA-C (like most embedded standards) bans all use of dynamic memory allocation. This rule makes very much sense in embedded systems, but not so much when it comes to the PC/desktop systems that dynamic allocation was designed for.
- Compliant 3rd party libraries are scarce.
When doing a strict implementation, MISRA-C should apply to all libraries used by the project. And 3rd party libraries for PC are certainly not MISRA-C compatible most of the time.
[]()
- Security/exploit concerns.
MISRA-C doesn't address PC-specific security concerns. It is a _safety_ standard, not a _security_ standard. Meaning that it focuses on writing code that is bug-free, but does not address malicious attempts to exploit the program. Things like code injection, buffer overruns etc are not addressed by MISRA-C.
- Restricted standard library use.
MISRA-C is very strict with which standard libraries it allows. In some cases this makes sense even in PC: don't use stdio.h, atoi family of functions, setjmp.h etc. But in some cases, MISRA-C comes across as overly pedantic: it doesn't allow `exit`, `signal.h`, `bsearch`, `qsort` etc.
- Conservative view of C.
For a long time, MISRA-C only supported C90. It wasn't until 2012 that C99 support was introduced, and then with lots of restrictions on C99-specific features. C11/C17 support has been added this year 2020 through Amendment 2, but it basically does that by banning every new feature. Things like pointer to VLA (C99) and `_Generic` (C11/C17) can be used to increase safety of programs, yet they are banned by MISRA-C, without much in the way of rationales.
You may of course deviate from rules such as the ones above - MISRA-C allows a formal deviation procedure.
In general though, the [CERT C](https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard) coding standard might be more suitable for hosted systems programming, since it is written to address such systems specifically. CERT C does take things like security in account and it's also available for free, from the link above. Usually CERT C provides a cross reference to MISRA-C, for a whole lot of rules are similar in both standards.
Both MISRA-C and CERT C have tool support by most static analysers on the market.
Overall, what's important is that you follow some manner of coding standard, even if it's just an internal one used by the company. MISRA-C and CERT C are professional standards, written by experts. They play in an entirely different league than for example the naive, amateur-level [Linux Kernel coding standard](https://www.kernel.org/doc/html/v4.10/process/coding-style.html), which I wouldn't recommend to use for other purposes than mere code formatting.

It is true that MISRA-C has a heavy focus on embedded system, though it has become somewhat more generic over time. The MISRA guidelines have been changed and improved several times over the years (in 1998, 2004 and 2012 + numerous TC and addendum/amendments). They are now definitely general enough to cover all embedded C programming, even outside automotive and safety-critical.
In general, MISRA-C is a good document for any form of C programming - I would recommend every C programmer to read it as learning material, even if not implementing it. The majority of the rules are sound and backed by sources and expertise.
There are however a couple of things that may make MISRA-C burdensome in PC/desktop ("hosted") systems programming:
- No heap allocation.
MISRA-C (like most embedded standards) bans all use of dynamic memory allocation. This rule makes very much sense in embedded systems, but not so much when it comes to the PC/desktop systems that dynamic allocation was designed for.
- Compliant 3rd party libraries are scarce.
When doing a strict implementation, MISRA-C should apply to all libraries used by the project. And 3rd party libraries for PC are certainly not MISRA-C compatible most of the time.
[]()
- Security/exploit concerns.
MISRA-C doesn't address PC-specific security concerns. It is a _safety_ standard, not a _security_ standard. Meaning that it focuses on writing code that is bug-free, but does not address malicious attempts to exploit the program. Things like code injection, buffer overruns etc are not addressed by MISRA-C.
- Restricted standard library use.
MISRA-C is very strict with which standard libraries it allows. In some cases this makes sense even in PC: don't use stdio.h, atoi family of functions, setjmp.h etc. But in some cases, MISRA-C comes across as overly pedantic: it doesn't allow `exit`, `signal.h`, `bsearch`, `qsort` etc.
- Conservative view of C.
For a long time, MISRA-C only supported C90. It wasn't until 2012 that C99 support was introduced, and then with lots of restrictions on C99-specific features. C11/C17 support has been added this year 2020 through Amendment 2, but it basically does that by banning every new feature. Things like pointer to VLA (C99) and `_Generic` (C11/C17) can be used to increase safety of programs, yet they are banned by MISRA-C, without much in the way of rationales.
You may of course deviate from rules such as the ones above - MISRA-C allows a formal deviation procedure.
In general though, the [CERT C](https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard) coding standard might be more suitable for hosted systems programming, since it is written to address such systems specifically. CERT C does take things like security into account and it's also available for free, from the link above. Usually CERT C provides a cross reference to MISRA-C, for a whole lot of rules are similar in both standards.
Both MISRA-C and CERT C have tool support by most static analysers on the market.
Overall, what's important is that you follow some manner of coding standard, even if it's just an internal one used by the company. MISRA-C and CERT C are professional standards, written by experts. They play in an entirely different league than for example the naive, amateur-level [Linux Kernel coding standard](https://www.kernel.org/doc/html/v4.10/process/coding-style.html), which I wouldn't recommend to use for other purposes than mere code formatting.

Communities

Review Suggested Edit