Page History

Redundant testing by caller and by callee as a style of defensive programming is largely discredited in the C and C++ communitycommunities, the main problem being performance. The usual discipline in C and C++ is to require validation on only one side of each interface.

...

/* setsSets some internal state in the library */
extern int setfile(FILE *file);

/* performsPerforms some action using the file passed earlier */
extern int usefile();

static FILE *myFile;

void setfile(FILE *file) {
    myFile = file;
}

void usefile(void) {
    /* performPerform some action here */
}

The vulnerability can be more severe if the internal state references sensitive or system-critical data.

...

/* setsSets some internal state in the library */
extern errno_t setfile(FILE *file);

/* performsPerforms some action using the file passed earlier */
extern errno_t usefile(void);

static FILE *myFile;

errno_t setfile(FILE *file) {
 if (file && !ferror(file) && !feof(file)) {
    myFile = file;
    return 0;
  }

  /* errorError safety: leave myFile unchanedunchanged */
  return -1;
}

errno_t usefile(void) {
  if (!myFile) return -1;

    /*
     * performPerform other checks if needed,; return 
     * error condition.
     */

    /* performPerform some action here */
    return 0;
}

...

Failing to validate the parameters in library functions may result in an access violation or a data integrity violation. Such a scenario indicates a flaw in how the library is used by the calling code. However, the library itself may still be the vector by which the calling code's vulnerability is exploited.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Key here (explains table format and definitions)

...

...

...

MITRE CWE: CWE ID 20, "Insufficient input validation"

...

Bibliography

...

...

Image Modified Image Modified Image Modified