Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Is MISRA-C useful outside safety-critical and embedded programming?

+8
−0

When discussing best or safest C programming practices with various C gurus on the Internet, the "MISRA-C guidelines for the use of C language in critical systems" often pops up as a source.

This standard was invented by the automotive industry and is pretty much mandatory in all automotive firmware nowadays. It has also become a widely-recognized de facto standard for embedded systems in general.

The argument for using it seems to be that the standard is mainly focusing on removing bugs, hazards and poorly-defined behavior and nobody likes bugs in their application, mission-critical or not.

Does it make sense to use MISRA-C outside embedded systems? For example when doing system or application C programming in Windows/Linux/Android etc.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+8
−0

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 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, which I wouldn't recommend to use for other purposes than mere code formatting.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

General comments (3 comments)

Sign up to answer this question »