Page History

Many functions return useful values whether or not the function has side effects. In most cases, this value is used to signify signifies whether the function successfully completed its task or if some error occurred. (See recommendation 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|AA. Bibliography#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 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 void.This recommendation encompasses rule MEM32-C. Detect and handle memory allocation errors, recommendation FIO04-C. Detect and handle input and output errors, and rule 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 occursopens a file, reads in its information, and closes it again.

puts("foo");

my $source;
open(my $SOURCE, "<", $source);
@lines = (<$SOURCE>);
close($SOURCE);

It makes sure the variable containing the file name is properly defined, but it does nothing else to catch errors. Consequently, any error, such as the file not existing, being unreadable, or containing too much data to read into memory, will cause the program to abortHowever, puts() can fail and return EOF.

Compliant Solution

This compliant solution checks to make sure no output error occurred. (See recommendation FIO04-C. Detect and handle input and output errors.)does the same thing but provides useful error messages if anything goes wrong.

if (puts("foo") == EOF) {
  /* Handle error */
}

Exceptions

my $source;
open(my $SOURCE, "<", $source) or croak "error opening $source: $!";
@lines = (<$SOURCE>);
close($SOURCE) or croak "error closing $source: $!";

If any error occurs, the program calls the croak() function, passing it a string that includes both the source file being opened and the $! variable, which contains a system error string based on the value of errno, which is set to a useful value when the open(2) or close(2) functions fail.

Exceptions

EXP32:EX0EXP12-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 recommendation 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.'s return value may be silently discarded.

EXP32:EX1: The autodie module is designed to replace functions that return a value indicating failure with functions that throw an exception on failure. When autodie is in use, any functions it redefines may be safely ignored.

strcpy(dst, src);

use autodie;

my $source;
open(my $SOURCE, "<", $source);
@lines = (<$SOURCE>);
close($SOURCE);

EXP32:EX2: Functions that send data to standard output or standard error need not have their return values checked. This includes print and printf, but only if their file handle argument is not supplied or is explicitly set to *STDOUT or *STDERR. If they send their output to any other file handle, their return value must be checked.

EXP32:EX3: When inside error-handling code, function calls that are used to release resources, such as close(), need not have their return values checked. Any code that falls under this exception should be explicitly documented as such.

Risk Assessment

Failure to handle error codes or other values returned by functions can lead to incorrect program flow and violations of data integrity.

Automated Detection

Related Guidelines

...

...

...

...

...

...

...

...

...

Bibliography

Image Added Image Added Image AddedEXP11-C. Do not apply operators expecting one type to data of an incompatible type      03. Expressions (EXP)      EXP13-C. Treat relational and equality operators as if they were nonassociative