CertC-DCL07¶

Include the appropriate type information in function declarators

Required inputs: IR

Function declarators must be declared with the appropriate type information, including a return type and parameter list. 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-C. Compile cleanly at high warning levels.)

Noncompliant Code Example (Non-Prototype-Format Declarators)

This noncompliant code example uses the identifier-list form for parameter declarations:

int max(a, b)
int a, b;
{
  return a > b ? a : b;
}

Subclause 6.11.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, 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;
}

Noncompliant Code Example (Function Prototypes)

Declaring a function without any prototype forces the compiler to assume that the correct number and type of parameters have been supplied to a function. This practice can result in unintended and undefined behavior.

In this noncompliant code example, the definition of func() in file_a.c expects three parameters but is supplied only two:

/* file_a.c source file */
int func(int one, int two, int three){
  printf("%d %d %d", one, two, three);
  return 1;
}

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:

/* 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:

/* file_b.c source file */
int func(int, int, int);

func(1, 2, 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:

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-C	Low	Unlikely	Low	P3	L3

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"

Excerpt from SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition) and SEI CERT C Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/recommendations/declarations-and-initialization-dcl/dcl07-c], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
cafe_message	{}	None	False
implicit_function_return_type	Function shall have explicit return type	None	False
implicit_int	Type shall be explicitly stated	None	False
missing_parameter_type	Functions shall have a prototype declaration	None	False
parameterless_func_without_void_param	Function with no parameters shall be declared with (void)	None	False
reference_to_missing_function_prototype	Referenced function needs prototype declaration	None	False
reference_to_undeclared_function	Referenced function needs a declaration	None	False

Options¶

This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

message_predicate¶

message_predicate : typing.Callable[[Cafe_Message], bool] | None = None

If provided, a custom predicate to filter relevant messages. Receives the message node and should return True for messages to report.

reported_messages¶

reported_messages : set[int] | None = {513}

If provided, only messages of these types are reported.

reported_severities¶

reported_severities : set[str] = {'error', 'remark', 'warning'}

List of severities to display.

use_error_number¶

use_error_number : bool = False

Whether the error number from the frontend should be used.

use_rule_severity¶

use_rule_severity : bool = True

Whether the rule's severity or the compiler's severity should be used.

Axivion Suite 7.12.0

Navigation