Page History

Do not call a function with the wrong number or type of arguments. 

The C Standard identifies five distinct situations in which undefined behavior (UB) may arise as a result of invoking a function using a declaration that is incompatible with its definition or by supplying incorrect types or numbers of arguments:

Functions that are appropriately declared (as in DCL40-C. Do not create incompatible declarations of the same function or object) will typically generate a compiler diagnostic message if they are supplied with the wrong number or types of arguments. However, there are cases in which supplying the incorrect arguments to a function will, at best, generate compiler warnings. Although such warnings should be resolved, they do not prevent program compilation. (See MSC00-C. Compile cleanly at high warning levels.)

Noncompliant Code Example

The header <tgmath.h> provides type-generic macros for math functions. Although most functions from the <math.h> header have a complex counterpart in <complex.h>, several functions do not. Calling any of the following type-generic functions with complex values is undefined behavior.

Functions That Should Not Be Called with Complex Values

This noncompliant code example attempts to take the base-2 logarithm of a complex number, resulting in undefined behavior:

#include <tgmath.h>
 
void func(void) {
  double complex c = 2.0 + 4.0 * I;
  double complex result = log2(c);
}

Compliant Solution (Complex Number)

If the clog2() function is not available for an implementation as an extension, the programmer can take the base-2 logarithm of a complex number, using log() instead of log2(), because log() can be used on complex arguments, as shown in this compliant solution:

#include <tgmath.h>
 
void func(void) {
  double complex c = 2.0 + 4.0 * I;
  double complex result = log(c)/log(2);
}

Compliant Solution (Real Number)

The programmer can use this compliant solution if the intent is to take the base-2 logarithm of the real part of the complex number:

#include <tgmath.h>
 
void func(void) {
  double complex c = 2.0 + 4.0 * I;
  double complex result = log2(creal(c));
}

Noncompliant Code Example

In this noncompliant example, the C standard library function strchr() is called through the function pointer fp declared with a prototype with incorrectly typed arguments. According to the C Standard, 6.3.2.3, paragraph 8 [ISO/IEC 9899:2024]

A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the referenced type, the behavior is undefined.

See undefined behavior 26.

Calling a function with incorrect arguments can result in unexpected or unintended program behavior. Functions that are appropriately declared \[[DCL07-A. Include the appropriate type information in function declarators]\] will typically fail compilation if they are supplied with the wrong number or types of arguments. However, there are cases where supplying the incorrect arguments to a function will only generate compiler warnings. These warnings should be resolved \[[MSC00-A. Compile cleanly at high warning levels]\], but do not prevent program compilation.

Non-Compliant Code Example: (function pointers)

In this example, the function pointer fp is used to refer to the function strchr(). However, fp is defined without the appropriate parameter list. As a result there is no type checking performed on the call to fp(12,2);.

#include <stdio.h>
#include <string.h>

char *(*fp) ();

int main(void) {
  const char *c;
  fp = strchr;
  c = fp(12'e', 2"Hello");
  printf("%s\n", c);
  return 0;
}

Note that this example violates recommendation \[[DCL35-C. Do not convert a function pointer to a function of an incompatible type]\].

Compliant Solution: (function pointers)

Compliant Solution

In this compliant solution, the function pointer fp, which points to the C standard library function strchr(), is declared with the correct parameters and is invoked with the correct number and type of arguments:Properly declaring fp so it is compatible with strchr() corrects this example.

#include <stdio.h>
#include <string.h>

char *(*fp)(const (char const *, int);

int main(void) {
  const char *c;
  fp = strchr;
  c = fp("Hello",'He');
  printf("%s\n", c);
  return 0;
}

...

Noncompliant Code Example

...

The POSIX function {{open()}} \[[Open Group 04|AA. C References#Open Group 04]\] is a variadic function with the following prototype:

int open(char const *path, int oflag, ... );

...

In this noncompliant example, the function f() is defined to take an argument of type long but f() is called from another file with an argument of type int:

Code Block
bgColor #FFCCCC lang c
/* ... In another source file */ int fd = open(file_name, O_CREAT | O_WRONLY); /* access permissions are missing */ if (fd == -1){ /* Handle Error */ } /* ... */

Compliant Solution: (variadic functions)

To correct this example, a third argument is specified in the call to open().

/* ... */
int fd = open(file_name, O_CREAT | O_WRONLY, file_access_permissions);
if (fd == -1){
  /* Handle Error */
}
/* ... */

Non-Compliant Code Example (argument validation)

Using a user-defined function to calculate the amount of memory to allocate is a common practice that may sometimes be necessary. However, if the function used to calculate the size parameter is flawed, then an incorrect size argument will be supplied to the allocation routine.

This following non-compliant code reads user-supplied data from standard input, returning the number of characters read.

#include <stdlib.h>
#include <stdio.h>

enum { MAXLINE = 1000 };

size_t calc() {
  char line[MAXLINE], c;
  size_t size = 0;
  while ( (c = getchar()) != EOF && c != '\n') {
    line[size] = c;
    size++;
    if (size >= MAXLINE)
      break;
  }
  return size;
}

int main(void) {
  char *line = malloc(calc());
  if (line == NULL) {
    /* Handle malloc() error */
  }
  /* ... */
  free(line);
}

However, if no characters are entered, {{calc()}} will return {{0}}. Because there is no validation on the result of {{calc()}}, a {{malloc(0)}} \[[MEM04-A. Do not make assumptions about the result of allocating 0 bytes]\] could occur, which could lead to a buffer overflow.

Compliant Solution (argument validation)

In this compliant solution, the result of calc() is not supplied directly to malloc(). Instead, the result of calc() is stored in the variable size and checked for the exceptional condition of being 0. This modification reduces the complexity of the line of code that calls malloc() and adds an additional layer of validation, thus reducing the chances of error.

long f(long x) {
  return x < 0 ? -x : x;
}

/* In this source file, no f prototype in scope */
long f();
 
long g(int x) {
  return f(x);
}

Compliant Solution

In this compliant solution, the prototype for the function f() is included in the source file in the scope of where it is called, and the function f() is correctly called with an argument of type long:

/* In another source file */
 
long f(long x) {
  return x < 0 ? -x : x;
}

/* f prototype in scope in this source file */

long f(long x); 

long g(int x) {
  return f((long)x);  
}

Noncompliant Code Example (POSIX)

The POSIX function open() [IEEE Std 1003.1:2013] is a variadic function with the following prototype:

int open(const char *path, int oflag, ... );

The open() function accepts a third argument to determine a newly created file's access mode. If open() is used to create a new file and the third argument is omitted, the file may be created with unintended access permissions. (See FIO06-C. Create files with appropriate access permissions.)

In this noncompliant code example from a vulnerability in the useradd() function of the shadow-utils package CVE-2006-1174, the third argument to open() is accidentally omitted:

fd = open(ms, O_CREAT | O_EXCL | O_WRONLY | O_TRUNC);

Technically, it is incorrect to pass a third argument to open() when not creating a new file (that is, with the O_CREAT flag not set).

Compliant Solution (POSIX)

In this compliant solution, a third argument is specified in the call to open():

#include <fcntl.h>
 
void func(const char *ms, mode_t perms) {
  /* ... */
  int fd;
  fd = open(ms, O_CREAT | O_EXCL | O_WRONLY | O_TRUNC, perms);
  if (fd == -1

#include <stdlib.h>
#include <stdio.h>

enum { MAXLINE = 1000 };

size_t calc() {
  char line[MAXLINE], c;
  size_t size = 0;
  while ( (c = getchar()) != EOF && c != '\n') {
    line[size] = c;
    size++;
    if (size >= MAXLINE)
      break;
  }
  return size;
}

int main(void) {
  size_t size = calc();
  if (!size) {
    /* Handle invalid size */
  }
  char *line = malloc(size)
  if (line == NULL) {
    /* Handle malloc() error */
  }
  /* ... */
  free(line);
}

Risk Assessment

Calling a function with incorrect arguments can result in unexpected or unintended program behavior.

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)

...

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-685 and EXP37-C

EXP37-C = Union( CWE-685, CWE-686) Intersection( CWE-685, CWE-686) = Ø

CWE-686 and EXP37-C

Intersection( EXP37-C, FIO47-C) =

• Invalid argument types passed to format I/O function

EXP37-C – FIO47-C =

• Invalid argument types passed to non-format I/O function

FIO47-C – EXP37-C =

• Invalid format string, but correctly matches arguments in number and type

EXP37-C = Union( CWE-685, CWE-686)

Intersection( CWE-685, CWE-686) = Ø

CWE-628 and EXP37-C

CWE-628 = Union( EXP37-C, list) where list =

• Improper ordering of function arguments (that does not violate argument types)

• Wrong argument values or references

Bibliography

...

Image Added Image Added Image Added

References

Wiki Markup\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Forward, Section 6.9.1, "Function definitions" \[[Spinellis 06|AA. C References#Spinellis 06]\] Section 2.6.1, "Incorrect Routine or Arguments"