Dynamic memory allocation or deallocation
ID |
c.correctness.avoid_dynamic_memory |
Severity |
low |
Remediation Complexity |
hard |
Remediation Risk |
high |
Remediation Effort |
high |
Resource |
Resource Management |
Language |
C / C++ |
Rationale
Dynamic (heap) allocation has an unbounded, data-dependent worst-case time and can fail at any point in a way that most embedded and safety-critical code paths never exercise in testing. Fragmentation from a long-running mix of allocations and frees can exhaust memory even when total live usage stays low, and a missed free/delete or a double-free is a defect class that static analysis cannot always rule out. Safety-critical and embedded coding standards (MISRA, JSF AV, many DO-178C profiles) therefore forbid dynamic allocation after initialization outright, in favor of statically or stack-allocated, bounded-size storage.
The following code illustrates the pattern detected by this rule:
void f1(void) {
// FLAGGED: Dynamic memory allocation or deallocation
int *p = (int *)malloc(sizeof(int));
// FLAGGED: Dynamic memory allocation or deallocation
free(p);
}