Limitations of C/C++ Code Sanitizer

The code sanitizer does not support multi-threaded code. Programs that use concurrency mechanisms such as POSIX threads, C11 threads, std::thread, std::jthread, std::async, or similar threading APIs may produce unreliable sanitizer results.

When a pointer to dynamically allocated memory is passed to a non-instrumented function, the sanitizer may lose track of the memory propagation. This can result in underreported leaked bytes or missed memory errors on the pointer arguments. A function is not instrumented when it is a standard function, or a user-defined function with no prototype or body, or is defined in a file that is not instrumented.

The sanitizer does not track pointer escape across different blocks within the same function. For instance, if a pointer is assigned the address of a local variable inside one block and dereferenced in a subsequent block after the local variable goes out of scope, the resulting use-after-scope error may not be detected.

The memset family of functions (memset, bzero, memset_s, memset_explicit, wmemset, and platform-specific variants) are not instrumented for memory safety or leak detection.

If a standard library function such as strdup is called without a visible prototype (implicit declaration), the sanitizer does not recognize the function as a standard function and skips instrumentation. This can result in missed memory leaks or other errors related to the function call.

The sanitizer does not detect memory errors involving C global pointers initialized at declaration using objects on stack.

Variable Length Arrays (VLAs) are not accurately supported. Out-of-bounds access on a VLA or use of a negative size in a VLA declaration may not be detected.

C complex types (_Complex) are not supported for numeric or memory instrumentation. Errors involving complex type arithmetic or standard complex math routines are not detected.

C++ STL containers (such as std::vector) and smart pointers (such as std::unique_ptr) are not instrumented. Out-of-bounds access or null pointer dereference errors that occur through these types are not detected.

Several C++ standard library objects and language constructs are not fully instrumented for memory safety. For instance, errors involving iostream operators, use-after-free through destructors, and operations on STL containers may not be detected.

Memory safety and leak attributes are not propagated through C++ constructor initializer lists. If a pointer is assigned in a member initializer list, defects related to that pointer may not be detected.

Calls through C++ pointers to member functions (PMF) are not instrumented. Defects caused by incorrect arguments passed through a PMF call, or invalid return values from a PMF call, are not detected.

Memory and leak defects are not detected on C++ class types whose default constructor, copy constructor, or copy assignment operator is deleted.

Memory leaks in C++ placement new constructors are not detected.

Memory leaks that occur inside a try block when an exception is thrown are not detected. Memory allocated before the exception is thrown may not be tracked for deallocation.

The sanitizer does not detect non-initialized variables or pointers.

The sanitizer does not detect memory leaks in guided mode.

Some run-time errors located within macro expansions may not be instrumented, even if Code Prover flags them as red or orange checks.

UNIX, POSIX, and BSD functions (such as read and file I/O functions) are not instrumented for memory safety, even if Code Prover reports errors involving these functions. The sanitizer currently instruments only ISO C89/C99 standard library functions.

Code Prover COR (Correctness Condition) checks are not instrumented. In particular, the FPPF (Function Pointer Points to valid Function) subcategory is not detected in guided mode.