Page History

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

...

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

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

static FILE *myFile;

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

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

...

Validating the function parameters and verifying the internal state leads to consistency of program execution and may eliminate potential vulnerabilities. In addition, implementing commit /or rollback semantics (leaving program state unchanged on error) is a desirable practice for error safety.

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

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

static FILE *myFile;

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

  /* error safety: leave myFile unchaned */
  return EINVAL;
}

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

    /* perform other checks if needed, return 
     * error condition */

    /* perform 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 is indicative of scenario indicates a flaw in the manner in which how the library is used by the calling code. However, it the library itself may still be the library itself that is the vector by which the calling code's vulnerability is exploited.

...

...

MITRE CWE: CWE ID 20, "Insufficient Input Validationinput validation"

Bibliography

[Apple 2006] Application Interfaces That Enhance Security, May 2006.

...