Function declarators must be declared with the appropriate type information, including a return type, parameter list, and function prototype (if the declarator is part of a function definition). If type information is not properly specified in a function declarator, the compiler cannot properly check function type information. When using standard library calls, the easiest (and preferred) way to obtain function declarators with appropriate type information is to include the appropriate header file.
Attempting to compile a program with a function declarator that does not include the appropriate type information typically generates a warning but does not prevent program compilation. These warnings should be resolved (see MSC00-A. Compile cleanly at high warning levels).
Non-Compliant Code Example (Non-Prototype-Format Declarators)
The non-compliant code example uses the identifier-list form for parameter declarations.
int max(a, b) int a, b; { return a > b ? a : b; }
Section 6.11 of the C99 standard, "Future language directions," states that "The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature."
Compliant Solution (Non-Prototype-Format Declarators)
In this compliant solution, int
is the type specifier, max(int a, int b)
is the function declarator, and the block within the curly braces is the function body.
int max(int a, int b) { return a > b ? a : b; }
Non-Compliant Code Example (Function Prototypes)
Failure to specify function prototypes results in a function being implicitly defined. Without a function prototype, the compiler assumes that the correct number and type of parameters have been supplied to a function. This can result in unintended and undefined behavior.
In this non-compliant code example, the definition of func()
expects three parameters but is supplied only two. However, because there is no prototype for func()
, the compiler assumes that the correct number of arguments has been supplied, and uses the next value on the program stack as the missing third argument.
int func(int one, int two, int three){ printf("%d %d %d", one, two, three); return 1; } /* ... */ func(1, 2);
C99 eliminated implicit function declarations from the C language [[ISO/IEC 9899-1999]]. However, many compilers still allow compilation of programs containing implicitly defined functions, although they may issue a warning message. These warnings should be resolved (see [MSC00-A. Compile cleanly at high warning levels]).
Compliant Solution (Function Prototypes)
To correct this example, the appropriate function prototype for func()
should be specified.
int func(int, int, int); /* ... */ int func(int one, int two, int three){ printf("%d %d %d", one, two, three); return 1; } /* ... */ func(1, 2, 3);
Non-Compliant Code Example (Function Pointers)
If a function pointer refers to an incompatible function, invoking that function via the pointer may corrupt the process stack. As a result, unexpected data may be accessed by the called function.
In this non-compliant code example, the function pointer fn_ptr
refers to the function add()
, which accepts three integer arguments. However, fn_ptr
is specified to accept two integer arguments. Setting fn_ptr
to refer to add()
results in unexpected program behavior. This example also violates the rule DCL35-C. Do not convert a function pointer to an incompatible type.
int add(int x, int y, int z) { return x + y + z; } int main(int argc, char *argv[]) { int (*fn_ptr) (int, int); int res; fn_ptr = add; res = fn_ptr(2, 3); /* incorrect */ /* ... */ return 0; }
Compliant Solution (Function Pointers)
To correct this example, the declaration of fn_ptr
is changed to accept three arguments.
int add(int x, int y, int z) { return x + y + z; } int main(int argc, char *argv[]) { int (*fn_ptr) (int, int, int) ; int res; fn_ptr = add; res = fn_ptr(2, 3, 4); /* ... */ return 0; }
Risk Assessment
Failing to include type information for function declarators can result in unexpected or unintended program behavior.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
DCL07-A |
1 (low) |
1 (unlikely) |
3 (low) |
P3 |
L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[ISO/IEC 9899-1999]] Forward and Section 6.9.1, "Function definitions"
[[MISRA 04]] Rule 8.2
[[Spinellis 06]] Section 2.6.1, "Incorrect Routine or Arguments"
DCL06-A. Use meaningful symbolic constants to represent literal values in program logic 02. Declarations and Initialization (DCL) DCL08-A. Properly encode relationships in constant definitions