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 guideline 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.
Section 6.8.3 of C99 [ISO/IEC 9899:1999] states that
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
. Since 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 void
.
This recommendation encompasses guidelines MEM32-C. Detect and handle memory allocation errors, FIO04-C. Detect and handle input and output errors, and FIO34-C. Use int to capture the return value of character IO functions.
Noncompliant Code Example
This noncompliant code example calls puts()
and fails to check whether a write error occurs.
puts("foo");
However, puts()
can fail and return EOF
.
Compliant Solution
This compliant solution checks to make sure no output error occurred. (See guideline FIO04-C. Detect and handle input and output errors.)
if (puts("foo") == EOF) { /* Handle error */ }
Exceptions
EXP12-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 the "compliant solution (Remove Existing Destination File)" under "Portable Behavior" section in guideline FIO10-C. Take care when using the rename() function.
EXP12-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 white list when automatic checkers are used.
strcpy(dst, src);
Risk Assessment
Failure to handle error codes or other values returned by functions can lead to incorrect program flow and violations of data integrity.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
EXP12-C |
medium |
unlikely |
medium |
P4 |
L3 |
Automated Detection
Tool |
Version |
Checker |
Description |
---|---|---|---|
2017.07 | CHECKED_RETURN |
finds inconsistencies in how function call return values are handled. Coverity Prevent cannot discover all violations of this recommendation, so further verification is necessary. |
|
Splint |
3.1.1 |
|
|
Compass/ROSE |
|
|
|
2024.3 | SV.RVT.RETVAL_NOTTESTED |
|
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
C++ Secure Coding Standard: EXP12-CPP. Do not ignore values returned by functions or methods
Java Secure Coding Standard: EXP00-J. Do not ignore values returned by methods
Bibliography
[ISO/IEC 9899:1999] Section 6.8.3, "Expression and null statements"
[ISO/IEC PDTR 24772] "CSJ Passing Parameters and Return Values"
[MITRE] CWE ID 754, "Improper Check for Unusual or Exceptional Conditions"
EXP11-C. Do not apply operators expecting one type to data of an incompatible type 03. Expressions (EXP)