Page History

According to the C Standard, subclause 6.7.6.3, paragraph 14 [ISO/IEC 9899:2011],

An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.

Subclause 6.11.6 states that

The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature.

Consequently, functions that accept no arguments Functions that take no parameters should explicitly declare a void parameter in their parameter list. This holds true in both the declaration and definition sections (which should match). Many compilers today still allow implicitly declared functions, even though C99 has eliminated them.unmigrated-wiki-markup

Defining a function with a void argument list differs from declaring it with no arguments because , in the latter case, the compiler will not check whether the function is called with parameters at all \[[C void usage|http://tigcc.ticalc.org/doc/keywords.html#void]\]. Consequently, function calling with arbitrary parameters will be accepted without a warning at compile [TIGCC, void usage]. Consequently, function calling with arbitrary parameters will be accepted without a warning at compile time.

Failure to declare a void parameter will result in

• an An ambiguous functional interface between the caller and callee.
• sensitive Sensitive information outflow.

A similar rule recommendation deals with parameter type in a more general sense: DCL07-C. Include the appropriate type information in function declarators.In C+, the usage of foo() and foo(void) has exactly the same meaning and effect, so this rule doesn't apply to C+. However, foo(void) should be declared explicitly instead of foo() to distinguish it from foo(...), which will then take arbitrary parameters.

Noncompliant Code Example (Ambiguous Interface)

In this noncompliant code example, the caller calls foo() with a parameter of 3an argument of 3. The caller expects foo() to accept a single int argument and to output the argument as part of a longer message. Because foo() is declared without the void parameter, the compiler will not perform any caller check. Due to the accidental internal implementation, the function foo() outputs the value 3, as the caller expects. In an inherited code base where foo and the caller are developed at different times, the caller will expect foo() to accept one integer as a parameter and to output the corresponding message when the parameter is changedIt is therefore possible that the caller may not detect the error. In this example, for instance, foo() might output the value 3 as expected.

Because no function parameter has the same meaning as an arbitrary parameter, the caller can feed provide an arbitrary number of parameters arguments to the function.

/* In foo.h */
void foo();

/* In foo.c */
void foo() {
  int i = 3;
  printf("i value: %d\n", i);
}

...

/* In caller.c */
#include "foo.h"

foo(3);

Compliant Solution (Ambiguous Interface)

In this compliant solution, void is specified explicitly as a parameter .in the declaration of foo's prototype:

/* In foo.h */
void foo(void);

/* compileIn using gcc4.3.3foo.c */
void foo (void) {
  int i = 3;
  printf("i value: %d\n", i);
}

/* In caller.c */
#include "foo.h"

foo(3);

Implementation Details (Ambiguous Interface)

When the above compliant solution is used and foo(3) is called, the GCC compiler will issue issues the following diagnostic, which alerts the programmer about the misuse of the function interface.:

error: too many arguments to function ‘foo’
"€˜foo"

Noncompliant Code Example (Information Outflow)

Another possible vulnerability is the leak of privileged information. In this noncompliant code example, a user with high privileges feeds some secret input to the caller that the caller then passes to foo(). Because of the way function foo() is defined, we might assume that there is no way for foo() to retrieve information from the caller. However, because the value of i is really passed into a stack (before the return address of the caller), a malicious programmer can change the internal implementation and copy the value manually into a less privileged file.

/* compileCompile using gcc4.3.3 */
void foo() {
  /* 
   * useUse asmassembly code to retrieve i
   * implicitly from caller
   * and transfer it to a less privilegeprivileged file.
   */
}

...

/* callerCaller */
foo(i); /* i is fed from user input */

Compliant Solution (Information Outflow)

void foo(void) {
  int i = 3;
  printf("i value: %d\n", i);
}

Again, the simplest solution is to explicitly specify void as the only parameter.

Risk Assessment

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

In C++, foo() and foo(void) have exactly the same meaning and effect, so this rule doesn't apply to C++. However, foo(void) should be declared explicitly instead of foo() to distinguish it from foo(.

References

...

..), which accepts an arbitrary number and type of arguments.

Bibliography

...

...

...

Image Added Image Added Image Added1999|AA. C References#ISO/IEC 9899-1999]\] Forward and Section 6.9.1, "Function definitions" \[[C void usage|http://tigcc.ticalc.org/doc/keywords.html#void]\]