MISRA-C Pointer Safety Analysis

1. Pointer Boundaries and Relational Operations

One of the most frequent sources of critical bugs is out-of-bounds memory access. MISRA provides a set of strict rules to ensure pointer arithmetic and comparisons stay within well-defined memory regions.

Rule 18.1: Confining Pointer Arithmetic

While we briefly discussed Rule 18.4 (preferring [] over +), Rule 18.1 is the underlying safety principle: A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand. This includes the address "one-past-the-end," but no further. Dereferencing that one-past-the-end pointer is strictly forbidden and leads to undefined behavior.

The following resource provides an excellent, in-depth analysis of this rule, including how static analysis tools interpret its nuances.

From that reading, consider these key analysis points:

• Calculating vs. Dereferencing: You can calculate a pointer to one-past-the-end of an array (e.g., int* p = &arr[10]; for a 10-element array), but you cannot dereference it (int x = *p; is a violation). This is crucial for loop termination conditions.
• Structs and Arrays: The distinction between &myStruct.elem1[11] (compliant, as the address is within the larger myStruct object) and myStruct.elem1[11] (non-compliant, as the access is outside the elem1 array bounds) is a sophisticated point that trips up many developers.
• Single Objects: A single variable is treated as an array of one element. Thus, int x; int* p = &x + 1; is compliant, but *p = 0; is not.

Rules 18.2 & 18.3: Pointer Subtraction and Comparison

Related to Rule 18.1 are the rules for how pointers can be compared.

• Rule 18.2: Subtraction between pointers shall only be applied to pointers that address elements of the same array.
• Rule 18.3: The relational operators > , >= , < and <= shall not be applied to objects of pointer type except where they point into the same object.

The rationale is straightforward: comparing or subtracting addresses of unrelated objects (e.g., two different local variables, or variables in different memory segments) gives a result that is implementation-defined and has no portable meaning.

#include <stdint.h>
#include <stddef.h>

void analyze_buffers(void) {
    uint32_t primary_buf[8];
    uint32_t secondary_buf[8];

    uint32_t *p1 = &primary_buf[0];
    uint32_t *p2 = &primary_buf[8]; // One past the end
    uint32_t *p3 = &secondary_buf[4];

    // Check 1
    if (p1 < p3) { 
        /* do something */
    }

    // Check 2
    ptrdiff_t diff = p2 - p3;

    // Check 3
    *p2 = 0xDEADBEEF; 
}

2. Pointers and Object Lifetime

A particularly dangerous category of bugs involves pointers that outlive the data they point to. These are called dangling pointers.

Rule 18.6: Address of an Object with Automatic Storage

The rule states: The address of an object with automatic storage shall not be copied to another object that persists after the first object has ceased to exist.

"Automatic storage" refers to local variables stored on the stack. When a function returns, its stack frame is deallocated, and any pointers to variables within that frame become invalid.

The following resource provides concise examples of this common and critical error.

Analyzing code for this violation means tracking where pointers are assigned. If you see the address-of operator (&) applied to a local variable, you must check if that address is:

1. Returned from the function.
2. Assigned to a global or static pointer.
3. Assigned to a pointer passed in as a function argument which is then stored elsewhere.

This type of bug can be maddening to debug, as the memory location might work correctly for a short time until the stack space is overwritten by a subsequent function call—a classic symptom you might have encountered when debugging with Trace32.

3. A Deeper Look at Pointer Conversion Violations

In the last lesson, we covered the most common casting rules. Now, let's broaden our analytical scope to spot a wider range of conversion-related violations. The following reading covers a catalog of these rules.

Let's highlight a few key rules for analysis:

• Rule 11.1 (Function Pointers): Casting between different function pointer types or between a function pointer and an object/integer pointer is forbidden. This is critical for event-driven systems or callback architectures (common in AUTOSAR) where type-safe function dispatch is essential.
• Rule 11.5 (void to object):** A conversion from void* to a pointer to object should not be implicit. This is a Required rule, meaning it can be deviated with justification. In C, malloc returns void*, and assigning its result to int *p is an implicit conversion. MISRA C:2012 requires an explicit cast (int *p = (int*)malloc(...)), though this is a point of debate in the wider C community. The key is that any such conversion must be deliberate and auditable.
• Rule 11.8 (Casting away qualifiers): A cast must not remove const or volatile. This is a mandatory safety rule. Casting away const can lead to modification of what should be read-only data. Casting away volatile is even more dangerous in an embedded context, as it tells the compiler it can optimize away reads/writes to a hardware register, breaking device driver logic.

#include <stdint.h>
#include <stdlib.h>

// Type for a generic handler
typedef void (*generic_handler_t)(void *data);

// Type for a specific handler
typedef void (*int_handler_t)(int *data);

void process_int(int *data) { /* ... */ }

void register_handler(generic_handler_t *handler_slot, const void *new_handler) {
    // Violation 1?
    *handler_slot = (generic_handler_t)new_handler; 
}

void dispatch(void) {
    const int payload = 123;
    int_handler_t specific_handler;

    // Violation 2?
    register_handler((generic_handler_t*)&specific_handler, &process_int);
    
    // Violation 3?
    specific_handler = (int_handler_t) &payload; 
}

Conclusion

Today you put on the hat of a static analysis tool, learning to spot critical MISRA C violations in code. We've seen that compliant pointer usage is about discipline: respecting array boundaries, understanding object lifetimes, and preserving the integrity of the type system.

Key Takeaways for Code Analysis:

• Boundary Checks: Always verify that pointer arithmetic, subtraction, and comparisons are confined to a single, valid object. Be extra vigilant about off-by-one errors that lead to dereferencing a one-past-the-end pointer.
• Scope and Lifetime: When you see the address of a local (stack) variable being taken, trace its usage. If it's returned or stored in a location with a longer lifetime, it's a dangling pointer violation (Rule 18.6).
• Conversion Scrutiny: Treat every pointer cast with suspicion. Check for conversions between incompatible function pointers (Rule 11.1), casts that discard qualifiers like const or volatile (Rule 11.8), and improper mixing of pointers and integers (Rule 11.4).

Mastering this analytical skill is invaluable. It not only helps you write better code but also allows you to more effectively review team members' code and correctly interpret the output from tools like Coverity and Helix QAC.

Preview of the Next Lesson

Detecting violations is the first half of the battle. The second, more constructive half, is fixing them. In our next lesson, we will focus on the final learning outcome of this module: Refactor non-compliant code involving pointers to meet MISRA-C standards and functional safety goals. We will take the non-compliant snippets from today and work through safe, compliant, and efficient alternatives.