Following the publication of MISRA C:2012 Amendment 4 in March 2023, the long-awaited release MISRA C:2023 was published by the MISRA organization in May. This is the third edition and second revision of the MISRA C standard. It updates and includes MISRA C:2012 Amendments 2 - 4 and Technical Corrigendum 2, providing the embedded industry and software teams developing C language versions according to ISO/IEC 9899:2011 (C11) and ISO/IEC 9899:2018 (C18) with an updated C coding standard that continues to target security vulnerabilities in the C language. Parasoft is involved in the standardization process and is a member of the MISRA C and C++ working groups. The C/C++test 2023 software testing solution provides full coverage for MISRA C:2023 and its predecessor MISRA C:2012 AMD (pictured). With C/C++test 2023.1, static code analyses can now be carried out in accordance with the current standard. This allows software developers to ensure that their code complies with the current MISRA coding standard.

Three new directives

The Parasoft Compliance Reporting module ensures that MISRA-compliant reports are available in Parasoft DTP and that test results are consolidated into intelligent dashboards, detailed reports and actionable analytics.

© Parasoft

MISRA C:2012 Amendment 4, i.e. MISRA C:2023, focuses on multithreading and the use of atomic functions. In particular, C11's built-in support for threads, atomic operations, mutual exclusion, condition variables and thread-specific memory. Multithreading is the ability of a CPU, supported by the operating system, to execute multiple threads simultaneously. Multithreaded applications can sometimes lead to unpredictable results, essentially running multiple parts of a program at the same time. For example, unpredictable problems occur when threads read and write shared data. This is why thread synchronization is so important in multithreading.

Three new guidelines on concurrency considerations have been created:

Policy 5.1 states that there must be no data race between threads. Therefore, threads must be protected by a synchronization mechanism. It is common to use a mutex (mutual exclusion) or a semaphore to prevent data races, e.g. read and write accesses to the same data at the same time. However, threads that lock data can cause their own problems, which is why guideline 5.2 specifies that there must be no deadlocks between threads. This is equivalent to absolutely no cyclic dependencies between threads. Due to the uncertainty of how many threads are running at any given time, guideline 5.3 is justified, according to which there must be no dynamic creation of threads. Threads can only be created when the program is started.

Support for C11 language features

MISRA C:2012 AMD4 has also created new rules to support C11 language features, especially for threading and through atomic functions <stdatomic.h>. The C11 language has introduced a number of atomic types and operations that make it possible to write portable multithreaded software that handles objects efficiently, indivisibly and without data races. To ensure this, the new rule 9.7 stipulates that atomic objects must be initialized appropriately before being accessed. Here is a simple example using the atomic_init() function:

_Atomic int32_t ai3;
atomic_init(&ai3, 333); /* Compliant */

The new rule 21.25 stipulates that all memory synchronization operations must be performed in a sequentially consistent order. C11 offers a series of library functions that implicitly use the strictest variant of the memory order "memory_order_seq_cst".

• atomic_store()
• atomic_load()
• atomic_exchange()
• atomic_compare_exchange_strong()
• atomic_compare_exchange_weak()
• atomic_fetch_add()
• atomic_fetch_sub()
• atomic_fetch_or()
• atomic_fetch_xor()
• atomic_fetch_and()
• atomic_flag_test_and_set()
• atomic_flag_clear()
• atomic_thread_fence()
• atomic_signal_fence()

"memory_order_seq_cst" provides a global read and write order, and sequentially consistent operations are visible in the same order in all threads.

Since a mutex is heavily dependent on synchronization, the MISRA-C working group has also worked extensively on hardening the use of C11 mtx_timedlock(). The mtx_timedlock() function blocks the current thread until the mutex it refers to is locked or until a specified timeout expires. However, if the current thread has already blocked the mutex and the mutex is not recursive or does not support a timeout, the behavior is undefined. Therefore, the new rule 21.26 states that the standard library function mtx_timedlock() may only be called for mutex objects of the corresponding mutex type. The first argument of the mtx_timedlock() function must be a mutex object of type mtx_timed or ( mtx_timed | mtx_recursive ). For this to work, the mutex object must be correctly initialized.

The new rule 22.14 requires the initialization of synchronization objects of threads before accessing these objects. Initializing all synchronization objects before creating the threads that access them is a deterministic way to prevent threads from accessing synchronization objects with indeterminate state. The C11 standard library function mtx_init() with a different type parameter value as listed below is considered undefined behavior and is not compliant:

• mtx_plain - a simple, non-recursive mutex.
• mtx_timed - a non-recursive mutex that supports timeout.
• mtx_plain | mtx_recursive - a recursive mutex.
• mtx_timed | mtx_recursive - a recursive mutex that supports timeout.

Additional rules should ensure that the use of concurrency or threads defined in C11 is safe, as well as synchronization, conditions and thread-local storage (table).

Of course, there are also some new rules that have nothing to do with concurrency. For example, the mandatory rule 18.10, which prohibits the use of pointers to variably modified array types. MISRA C:2012 AMD 4 contains a total of three new guidelines and 19 new rules. Parasoft C/C++test 2023.1 also offers full support here, as well as for MISRA C:2023.