Functions should always Function declarators must be declared with the appropriate function prototype. If a function prototype is not availabletype information, including a return type and parameter list. If type information is not properly specified in a function declarator, the compiler cannot perform checks on the number and type of arguments being passed to functions. Argument type checking in C is only performed during compilation, and does not occur during linking, or dynamic loading.
Non-Compliant Code Example
This non-compliant program makes use of function declarators with empty parentheses. Consequently, the program compiles cleanly at high warning levels but contains serious errors.
Code Block | ||
---|---|---|
| ||
#include <stdio.h>
extern char *strchr();
int main(void) {
char *c = strchr(12, 5);
printf("Hello %c!\n", *c);
}
|
Section 6.11 of the C99 standards, "Future language directions", states that "The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature." The use of these declarations prevents the compiler from performing type checking.
Compliant Solution
The following compliant solution includes the header file containing the appropriate library function prototype.
Code Block | ||
---|---|---|
| ||
#include <stdio.h>
#include <string.h>
int main(void) {
char *c = strchr("world", 'w');
printf("Hello %c!\n", *c);
}
|
Non-Compliant Code Example
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-C. Compile cleanly at high warning levels.)
Noncompliant Code Example (Non-Prototype-Format Declarators)
This noncompliant The non-compliant code example uses the identifier-list form for the parameter declarations.:
Code Block | ||||
---|---|---|---|---|
| ||||
extern int max(a, b)
int a, b;
{
return a > b ? a : b;
}
|
Section Subclause 6.11 of the C99 standards, "Future language directions", states that "The .7 of the C Standard [ISO/IEC 9899:2011] 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, extern
is the storage-class specifier and 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.:
Code Block | ||||
---|---|---|---|---|
| ||||
extern int max(int a, int b) { return a > b ? a : b; } |
...
Noncompliant Code Example
...
(Function Prototypes)
Declaring a function without any prototype forces the compiler to assume that Failure to specify function prototypes results in a function being implicitly defined. Without a function prototype, the compiler assumes the the correct number and type of parameters have been supplied to a function. This practice can result in unintended and undefined behavior.
In this non-compliant noncompliant code example, the definition of func()
in file_a.c
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.:
Code Block | ||||
---|---|---|---|---|
| ||||
func(1, 2); /* ...file_a.c source file */ int func(int one, int two, int three){ printf("%d %d %d", one, two, three); return 1; } |
Wiki Markup |
---|
C99 eliminated implicit function declarations from the C language \[[ISO/IEC 9899-1999:TC2|AA. C References#ISO/IEC 9899-1999TC2]\]. However, many compilers allow compilation of programs containing implicitly defined functions, although they may issue a warning message. These warnings should be resolved \[[MSC00-A|MSC00-A. Compile cleanly at high warning levels]\], but do not prevent program compilation. |
Compliant Solution
To correct this example, the appropriate function prototype for func()
should be specified.
However, because there is no prototype for func()
in file_b.c
, 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:
Code Block | ||||
---|---|---|---|---|
| ||||
/* file_b.c source file */
func(1, 2);
|
C99 eliminated implicit function declarations from the C language. However, many compilers still allow the compilation of programs containing implicitly declared functions, although they may issue a warning message. These warnings should be resolved. (See MSC00-C. Compile cleanly at high warning levels.)
Compliant Solution (Function Prototypes)
This compliant solution correctly includes the function prototype for func()
in the compilation unit in which it is invoked, and the function invocation has been corrected to pass the right number of arguments:
Code Block | ||||
---|---|---|---|---|
| ||||
/* file_b.c source file */ | ||||
Code Block | ||||
| ||||
int func(int, int, int); /* ... */ func(1, 2); /* ... */ int func(int one, int two, int three){ printf("%d %d %d", one, two, three); return 1; } |
Non-Compliant Code Example
Wiki Markup |
---|
The following example is based on rule \[[MEM02-A|MEM02-A. Do not cast the return value from malloc()]\]. The header file {{stdlib.h}} contains the function prototype for {{malloc()}}. Failing to include {{stdlib.h}} causes {{malloc()}} to be implicitly defined. |
Code Block | ||
---|---|---|
| ||
char *p = malloc(10);
|
Compliant Solution
Including stdlib.h
ensures the function prototype for malloc()
is declared.
, 3);
|
Noncompliant 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 noncompliant 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 EXP37-C. Call functions with the correct number and type of arguments:
Code Block | ||||
---|---|---|---|---|
| ||||
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:
Code Block | ||||
---|---|---|---|---|
| ||||
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);
| ||||
Code Block | ||||
| ||||
#include <stdlib.h> /* ... */ char *p = malloc(10);return 0; } |
Risk Assessment
Failure to specify function prototypes Failing to include type information for function declarators can result in undefined, and perhaps unexpected or unintended program behavior.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
DCL07-C |
1 (low)
1 (unlikely)
Low | Unlikely | Low | P3 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| function-prototype implicit-function-declaration | Partially checked | ||||||
Axivion Bauhaus Suite |
| CertC-DCL07 | |||||||
CodeSonar |
| LANG.FUNCS.PROT LANG.STRUCT.DECL.IMPT | Incomplete function prototype Implicit Type | ||||||
| CC2.DCL07 | Fully implemented | |||||||
GCC |
| Can detect violation of this recommendation when the | |||||||
Helix QAC |
| C1304, C2050, C3331, C3335, C3408, C3450 | |||||||
Klocwork |
| MISRA.FUNC.PROT_FORM.KR.2012 MISRA.FUNC.NOPROT.DEF MISRA.CAST.FUNC_PTR.2012 | |||||||
LDRA tool suite |
| 21 S | Fully implemented | ||||||
PC-lint Plus |
| 718, 746, 936, 9074 | Fully supported | ||||||
Polyspace Bug Finder |
| Checks for:
Rec. fully covered. | |||||||
RuleChecker |
| function-prototype implicit-function-declaration | Partially checked | ||||||
SonarQube C/C++ Plugin |
| S819, S930 |
Related Vulnerabilities
Search for Examples of vulnerabilities resulting from the violation of this rule can be found on the CERT website.
References
Wiki Markup |
---|
\[[ISO/IEC 9899-1999:TC2|AA. C References#ISO/IEC 9899-1999TC2]\] Forward, Section 6.9.1, "Function definitions" |
...
Related Guidelines
ISO/IEC TR 24772:2013 | Type System [IHN] Subprogram Signature Mismatch [OTR] |
ISO/IEC TS 17961 | Using a tainted value as an argument to an unprototyped function pointer [taintnoproto] |
MISRA C:2012 | Rule 8.2 (required) |
Bibliography
[ISO/IEC 9899:2011] | Subclause 6.11.7, "Function Definitions" |
[Spinellis 2006] | Section |
...
2.6.1, |
...
"Incorrect |
...
Routine |
...
or |
...
Arguments" |
...