All standard library functions, including I/O functions and memory allocation functions, return either a valid value or a value of the correct return type that indicates an error (for example, −1 or a null pointer). Assuming that all calls to such functions will succeed and failing to check the return value for an indication of an error is a dangerous practice that may lead to unexpected or undefined behavior when an error occurs. It is essential that programs detect and appropriately handle all errors in accordance with an error-handling policy, as discussed in ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy. In addition to the C standard library functions mentioned in ERR33-C. Detect and handle standard library errors, the following functions defined in POSIX require error checking (list is not all-inclusive).
The successful completion or failure of each of the standard library functions listed in the following table shall be determined either by comparing the function’s return value with the value listed in the column labeled “Error Return” or by calling one of the library functions mentioned in the footnotes to the same column.
Pointer to a
Pointer to a
errno is a POSIX [ISO/IEC 9945:2008] extension to the C Standard. On error,
posix_memalign() returns a value that corresponds to one of the constants defined in the
<errno.h> header. The function does not set
posix_memalign() function is optional and is not required to be provided by POSIX-conforming implementations.
Noncompliant Code Example (POSIX)
In this noncompliant code example,
open_memstream() are assumed to succeed. However, if the calls fail, the two file pointers
out will be null and the program will have undefined behavior.
Compliant Solution (POSIX)
A compliant solution avoids assuming that
open_memstream() succeed regardless of its arguments and tests the return value of the function before using the file pointers
POS54-C-EX1: This exception has been removed.
POS54-C-EX2: The exception from ERR33-C. Detect and handle standard library errors (that is ERR33-C-EX1) applies to this rule. See that exception for more information.
Failing to detect error conditions can lead to unpredictable results, including abnormal program termination and denial-of-service attacks or, in some situations, could even allow an attacker to run arbitrary code.
|Axivion Bauhaus Suite|
|Ignored return value|
Missing Test of Error Code
Non-zero Error Code
Can detect violations of this recommendation when checking for violations of EXP12-C. Do not ignore values returned by functions and EXP34-C. Do not dereference null pointers
Finds inconsistencies in how function call return values are handled. Coverity Prevent cannot discover all violations of this recommendation, so further verification is necessary
|LDRA tool suite|
The value returned by a POSIX library function that may return an error should be used
413, 534, 613
|CERT C: Rule POS54-C||Checks for situations where return value of a sensitive function is not checked (rule fully covered)|
The VU#159523] arises because Flash neglects to check the return value from
calloc(). Even when
NULL, Flash writes to an offset from the return value. Dereferencing
NULL usually results in a program crash, but dereferencing an offset from
NULL allows an exploit to succeed without crashing the program.
Key here (explains table format and definitions)
|[DHS 2006]||Handle All Errors Safely|
|[Henricson 1997]||Recommendation 12.1, "Check for All Errors Reported from Functions"|
|[ISO/IEC 9899:2011]||Subclause 18.104.22.168, "The |