Many functions return useful values whether or not the function has side effects. In most cases, this value is used to signify whether the function successfully completed its task or if some error occurred (see ERR02-C. Avoid in-band error indicators). Other times, the value is the result of some computation and is an integral part of the function's API.
Subclause 6.8.3 of the C Standard [ISO/IEC 9899:2011] states:
The expression in an expression statement is evaluated as a void expression for its side effects.
All expression statements, such as function calls with an ignored value, are implicitly cast to
void. Because a return value often contains important information about possible errors, it should always be checked; otherwise, the cast should be made explicit to signify programmer intent. If a function returns no meaningful value, it should be declared with return type
This recommendation encompasses ERR33-C. Detect and handle standard library errors. Unlike this recommendation, that rule is restricted to functions from the Standard C library.
Compliance with this recommendation is required in order to comply with ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy
Noncompliant Code Example
This noncompliant code example calls
fputs() and fails to check whether a write error occurs:
fputs() can fail and return
This compliant solution checks to make sure no output error occurred (see ERR33-C. Detect and handle standard library errors).
EXP12-C-EX1: If the return value is inconsequential or if any errors can be safely ignored, such as for functions called because of their side effects, the function should be explicitly cast to
void to signify programmer intent. For an example of this exception, see "Compliant Solution (Remove Existing Destination File)" under the section "Portable Behavior" in FIO10-C. Take care when using the rename() function, or Exception ERR33-C-EX1 in ERR33-C. Detect and handle standard library errors.
EXP12-C-EX2: If a function cannot fail or if the return value cannot signify an error condition, the return value may be ignored. Such functions should be added to a whitelist when automatic checkers are used.
Failure to handle error codes or other values returned by functions can lead to incorrect program flow and violations of data integrity.
|Axivion Bauhaus Suite|
|LANG.FUNCS.IRV||Ignored return value|
Finds inconsistencies in how function call return values are handled. Coverity Prevent cannot discover all violations of this recommendation, so further verification is necessary
Return value of memory allocation function is not used.
Ignored return value from function when configuration says it must be used. See the chapter "Library configuration" in the cppcheck manual
|LDRA tool suite|
The value returned by a function having non-void return type shall be used
|Returned value of a sensitive function not checked||Sensitive functions called without checking for unexpected return values and errors|
|V530, V698, V757, V797|
|SEI CERT C++ Coding Standard||VOID EXP12-CPP. Do not ignore values returned by functions or methods|
|CERT Oracle Secure Coding Standard for Java||EXP00-J. Do not ignore values returned by methods|
|ISO/IEC TR 24772:2013||Passing Parameters and Return Values [CSJ]|
|MITRE CWE||CWE-754, Improper check for unusual or exceptional conditions|
|[ISO/IEC 9899:2011]||Subclause 6.8.3, "Expression and Null Statements"|