22-05-2009, 12:47 PM
Rule 8.1 states, "Functions shall have prototype declarations and the prototype shall be visible at both the function definition and call."
My question concerns a subset situation of this rule: why should functions marked static have prototype declarations visible at the function definition?
Here is an example of the scenario, all in the same .c file:
static int8_t my_function( void );
...
float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}
static int8_t my_function( void )
{
...
}
Elsewhere in the file there my be other calls of my_function too. This file conforms to rule 8.1. If I re-arrange the textual order of the file to make sure that the definition of my_function occurs before any calls of it, then the prototype effectively becomes redundant:
static int8_t my_function( void );
static int8_t my_function( void )
{
...
}
...
float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}
Realistically, the prototype for my_function, usually placed towards the top of the .c file, is done by copy and paste from the function definition, with a semicolon added to the end of it. To me, as long as the textual order is right, the prototype just becomes something with no value to maintain, e.g. if you were to alter the function signature you would have to do so in two places rather than just one.
I have tried to work out why MISRA would want the rule as it is, inclusive of static functions. (I'm ok with the rule otherwise.) I reckon that it might be for this reason: the prototype for static functions are there for the day when someone does some maintenance on the .c file and adds a call to a static function textually before the definition of the function. With a prototype there, the call would be checked for consistency; without a prototype there, if the maintainer forgets to alter the textual order of the function definitions, the function call is unchecked and so has a risk of being in error.
Have I answered my own question?
My question concerns a subset situation of this rule: why should functions marked static have prototype declarations visible at the function definition?
Here is an example of the scenario, all in the same .c file:
static int8_t my_function( void );
...
float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}
static int8_t my_function( void )
{
...
}
Elsewhere in the file there my be other calls of my_function too. This file conforms to rule 8.1. If I re-arrange the textual order of the file to make sure that the definition of my_function occurs before any calls of it, then the prototype effectively becomes redundant:
static int8_t my_function( void );
static int8_t my_function( void )
{
...
}
...
float64_t my_other_function( void )
{
...
my_int8_var = my_function();
...
}
Realistically, the prototype for my_function, usually placed towards the top of the .c file, is done by copy and paste from the function definition, with a semicolon added to the end of it. To me, as long as the textual order is right, the prototype just becomes something with no value to maintain, e.g. if you were to alter the function signature you would have to do so in two places rather than just one.
I have tried to work out why MISRA would want the rule as it is, inclusive of static functions. (I'm ok with the rule otherwise.) I reckon that it might be for this reason: the prototype for static functions are there for the day when someone does some maintenance on the .c file and adds a call to a static function textually before the definition of the function. With a prototype there, the call would be checked for consistency; without a prototype there, if the maintainer forgets to alter the textual order of the function definitions, the function call is unchecked and so has a risk of being in error.
Have I answered my own question?