MISRA.FUNC.UNMATCHED.PARAMS

MISRA C 2012 Rule 8.2: Function types shall be in prototype form with named parameters

C90 [Undefined 22-25], C99 [Undefined 36-39, 73, 79]

Category: Required

Analysis: Decidable, Single Translation Unit

Applies to: C90, C99

Rationale

The early version of C, commonly referred to as K&R C [30], did not provide a mechanism for checking the number of arguments or their types against the corresponding parameters. The type of an object or function did not have to be declared in K&R C since the default type of an object and the default return type of a function was int.

The C90 standard introduced function prototypes, a form of function declarator in which the parameter types were declared. This permitted argument types to be checked against parameter types. It also allowed the number of arguments to be checked except when a function prototype specified that a variable number of arguments was expected. The C90 standard did not require the use of function prototypes for reasons of backward compatibility with existing code. For the same reason, it continued to permit types to be omitted in which case the type would default to int.

The C99 standard removed the default int type from the language but continued to allow K&R-style function types in which there was no means to supply parameter type information in a declaration and it was optional to supply parameter type information in a definition.

The mismatch between the number of arguments and parameters, their types and the expected and actual return type of a function provides potential for undefined behaviour. The purpose of this rule along with Rule 8.1 and Rule 8.4 is to avoid this undefined behaviour by requiring parameter types and function return types to be specified explicitly. Rule 17.3 ensures that this information is available at the time of a function call, thereby requiring the compiler to diagnose any mismatch that is detected.

Example

The first example shows declarations of some functions and the corresponding definitions for some of those functions.

/* Compliant                                                  */
extern int16_t func1 ( int16_t n );

/* Non-compliant - parameter name not specified               */
extern void func2 ( int16_t );

/* Non-compliant - not in prototype form                      */
static int16_t func3 ( );

/* Compliant - prototype specifies 0 parameters               */
static int16_t func4 ( void );

/* Compliant                                                  */
int16_t func1 ( int16_t n )
{
    return n;
}

/* Non-compliant - old style identifier and declaration list  */
static int16_t func3 ( vec, n )
int16_t *vec;
int16_t n;
{
    return vec[ n - 1 ];
}

This example section shows the application of the rule to function types other than in function declarations and definitions.

/* Non-compliant - no prototype                      */
int16_t ( *pf1 ) (  );

/* Compliant - prototype specifies 0 parameters      */
int16_t ( *pf1 ) ( void );

/* Non-compliant - parameter name not specified      */
typedef int16_t ( *pf2_t ) ( int16_t );

/* Compliant                                         */
typedef int16_t ( *pf3_t ) ( int16_t n );

MISRA C 2012 Rule 17.3: A function shall not be declared implicitly

C90 [Undefined 6, 22, 23]

Category: Mandatory

Analysis: Decidable, Single Translation Unit

Applies to: C90

Rationale

Provided that a function call is made in the presence of a prototype, a constraint ensures that the number of arguments matches the number of parameters and that each argument can be assigned to its corresponding parameter.

If a function is declared implicitly, a C90 compiler will assume that the function has a return type of int. Since an implicit function declaration does not provide a prototype, a compiler will have no information about the number of function parameters and their types. Inappropriate type conversions may result in passing the arguments and assigning the return value, as well as other undefined behaviour.

Example

If the function power is declared as:

extern double power ( double d, int n );

but the declaration is not visible in the following code then undefined behaviour will occur.

void func ( void ) 
{
  /* Non-compliant - return type and both argument type s incorrect */ 
  double sq1 = power ( 1, 2.0 );
}

See also

Rule 8.2, Rule 8.4

MISRA-C 2004 Rule 16.6 (required): The number of arguments passed to a function shall match the number of parameters.

The number of formal and actual parameters passed to a function do not match.

[Undefined 22]

This problem is completely avoided by the use of function prototypes — see Rule 8.1. This rule is retained since compilers may not flag this constraint error.