Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Adopting Safe Dynamic Memory Allocation in C: A Guide to CAN/CSA-ISO/IEC TR 24731‑2‑12:2016
Understanding the Canadian Implementation of ISO/IEC Technical Report 24731‑2 for Extended C Library Functions
Scope and Purpose of CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016
CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016 is the Canadian national adoption of the International Technical Report ISO/IEC TR 24731‑2:2012 — Information technology — Programming languages, their environments and system software interfaces — Extensions to the C library — Part 2: Dynamic allocation functions. This Technical Report provides a set of portable, secure extensions to the C standard library that address common pitfalls associated with dynamic memory management.
The primary scope of this document is to define functions that offer safer alternatives to traditional C library routines (such as malloc, calloc, and free) while maintaining compatibility with existing code bases. It focuses on:
- Reducing the risk of memory leaks, double‑free errors, and buffer overflows.
- Providing alignment‑aware allocation for improved performance on modern hardware.
- Enabling easy duplication of strings without exposing the programmer to manual length calculations.
Technical Requirements and Key Features
The Technical Report introduces a number of new functions, each designed to fill a specific gap in the standard C library. The following table summarises the principal functions specified in CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016.
| Function | Prototype | Description | Safety Benefit |
|---|---|---|---|
aligned_alloc | void *aligned_alloc(size_t alignment, size_t size); | Allocates memory with a specified alignment boundary. | Ensures that allocated memory meets alignment requirements (e.g., for SIMD instructions or atomic operations). |
reallocarray | void *reallocarray(void *ptr, size_t nmemb, size_t size); | Reallocates memory for an array of nmemb elements, each of size bytes. Checks for integer overflow in the product. | Prevents integer‑overflow vulnerabilities that can lead to heap overflows. |
reallocf | void *reallocf(void *ptr, size_t size); | Behaves like realloc but frees the original block on failure. | Eliminates memory leaks when a reallocation fails. |
strdup | char *strdup(const char *s); | Duplicates a null‑terminated string using malloc. | Abstracts manual length calculation and allocation, reducing off‑by‑one errors. |
strndup | char *strndup(const char *s, size_t n); | Duplicates at most n characters of a string. | Provides bounded duplication, preventing over‑reads from non‑terminated strings. |
All functions are required to return a pointer to the allocated memory or a null pointer (with errno set) when the allocation fails. The report also recommends that implementations support a calloc variant that checks for overflow, though that is not mandatory.
Tip: When migrating legacy code, replacing
malloc(n * size) with calloc(n, size) is a quick win against integer overflows. For existing realloc patterns, reallocarray or reallocf are strong candidates for incrementally improving safety. Implementation Highlights and Portability
Adopting the functions defined in CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016 does not require a complete rewrite of an application. Instead, these extensions can be introduced gradually:
- Use
strdup/strndupwherever string duplication is needed; they are already widely available on many platforms (POSIX, BSD, Linux) and are simple to fallback if missing. - Replace manual multiplication patterns such as
malloc(n * sizeof(T))withcalloc(n, sizeof(T))or, for reallocation, withreallocarrayto automatically detect overflow. - Employ
aligned_allocfor performance‑critical code that benefits from cache‑line or vector‑register alignment. Note that the alignment must be a power of two and at least the size of a pointer.
Important: The functions
reallocf and reallocarray originate from the BSD family of operating systems and are not yet universally available. Before relying on them in cross‑platform code, verify that the target environment provides them or supply a compatible implementation. Portability is a key concern for any extension library. The Technical Report encourages implementors to follow precisely the specified semantics so that code can move between systems without hidden behavioural differences. Because the report is not a formal International Standard (it is a Technical Report), it does not carry the same normative weight as, for example, ISO/IEC 9899. Nevertheless, many C compiler vendors and standard library developers have adopted these functions in whole or in part.
Compliance Notes and Adoption Context
CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016 is classified as a Technical Report, not a standard. Compliance is therefore voluntary. However, the report has been influential in guiding the evolution of the C language. Several of its functions were incorporated into the optional Annex K (Bounds‑checking interfaces) of the C11 standard, although the dynamic allocation functions themselves have not been added to the core language standard as of C17 or C23.
Adoption in Canada: As a CSA‑adopted Technical Report, this document represents a Canadian position on safe dynamic allocation practices. Organisations that follow CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016 can demonstrate alignment with internationally recognised security guidelines, which may be a requirement for government or safety‑critical software projects.
Caution: Because several functions (e.g.,
reallocarray) are not part of the ISO C standard, they may not be available on all compilers. Relying exclusively on these extensions can reduce code portability. Always provide an implementation fallback or guard with feature‑test macros (_GNU_SOURCE, _BSD_SOURCE, or a dedicated HAVE_REALLOCARRAY check). When claiming compliance with CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016, developers should document which functions are used and ensure the implementation matches the semantics described in the report. Testing of edge cases (zero‑size allocation, alignment, overflow detection) is strongly recommended.
Frequently Asked Questions
Q: Is CAN/CSA‑ISO/IEC TR 24731‑2‑12:2016 an official Canadian standard?
A: It is a Technical Report adopted by the Canadian Standards Association (CSA Group) without modification from ISO/IEC TR 24731‑2:2012. It is not a normative “standard” in the traditional sense, but it provides authoritative guidance for secure C programming practices in Canada.
A: It is a Technical Report adopted by the Canadian Standards Association (CSA Group) without modification from ISO/IEC TR 24731‑2:2012. It is not a normative “standard” in the traditional sense, but it provides authoritative guidance for secure C programming practices in Canada.
Q: What is the relationship between this Technical Report and the C11/C23 standard?
A: Some functions (e.g.,
A: Some functions (e.g.,
aligned_alloc) were added to the C11 standard directly. Others, like reallocarray and strndup, are not part of the ISO C standard but are widely available on systems with POSIX or BSD extensions. This TR remains relevant because it consolidates and recommends these functions as a coherent extension set. Q: How can I check whether my compiler supports these functions?
A: Use feature‑test macros such as
A: Use feature‑test macros such as
_POSIX_C_SOURCE, _GNU_SOURCE, or _DEFAULT_SOURCE on Linux; on BSD systems these functions are generally present by default. To be safe, you can implement compatibility wrappers that fall back to standard calls when the extension is missing. Q: Does this Technical Report replace the standard C memory functions?
A: No. It is intended to augment them. Existing programs can remain unchanged; the extensions merely provide safer alternatives. Where possible, new code should prefer these functions to reduce the risk of memory‑related bugs.
A: No. It is intended to augment them. Existing programs can remain unchanged; the extensions merely provide safer alternatives. Where possible, new code should prefer these functions to reduce the risk of memory‑related bugs.