* please cite extra references in text or references section, but not both
* this rule is targeted to {cpp}, but I'm not sure it's appropriate - you can have default parameter values in {cpp} but not in C. Unless at implementation time there's an intent to ignore the mismatch when covered by default values?
\[~samuel.mercier], [~ann.campbell.2], [~freddy.mallet], guys, I'm a little bit puzzled about what we want to achieve here and thus about how this rule should be implemented.
According to C99 6.5.2.2p2:
____
If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters.
____
So one option to violate this - compiler should not conform with C99, which sounds unbelievable in 2014. But let's try:
{noformat:title=1.c}
void fun(int p) {
}
void test() {
fun();
}
{noformat}
This is not accepted by GCC 4.7.3, Clang 3.5.0, ICC 14.0.3 20140422 (invoked with "-fsyntax-only --std c89") with error message "too few arguments to function call". Should we try with older compilers? How old? 1, 2, 5 years old?
Another option to violate this - do not use prototype:
{noformat:title=2.c}
void fun() {
}
void test() {
fun(42);
}
{noformat}
And indeed in this case no messages with GCC, but warning with Clang and ICC - "too many arguments in call to 'fun'". But then IMO this is covered by MISRA C:2004, 16.5 (RSPEC-929), which clearly requires to specify "void" and so implies prototype, or MISRA C:2004, 8.1 (RSPEC-819), which I assume implies requirement of prototype.
Third option to violate this - use implicit function declaration, which also means no prototype:
{noformat:title=3.c}
void test() {
fun(42);
}
{noformat}
Same result as in second case. But then IMO this is covered by MISRA C:2004, 8.1 (RSPEC-819) as before, or by MISRA C:2012 17.3, which clearly forbids implicit function declaration and I suppose also should be part of RSPEC-819.
Fourth option to violate this - use K&R style of function definition, which also means no prototype:
{noformat:title=4.c}
void fun(p)
int p;
{
}
void test() {
fun(42);
}
{noformat}
Same result. But then IMO this is covered by RSPEC-1198, which clearly forbids K&R style.
The difference between mentioned rules and this one - others are about declarations, whereas this about call-sites. So that if all enabled, then we'll simply get more violations. And thus the only valid use-case for this one - when others are disabled, or when there is no way to fix declaration, i.e. when it comes from third-party header file.
I have a few responses to your comment. Rather than choosing, I'll list them all:
1) The varargs argument is one of the things that came to mind when I read this rule, but as you're about to point out, there's another rule for that.
2) We can't make assumptions about the compilers in use. Probably a frightening number of places are supporting ancient infrastructure (incl. compilers) because "it works; don't mess with it!". (I've seen this in action.)
3) We have another rule already implemented that's about code that won't easily compile with modern compilers. If we're going for full MISRA coverage (as full as possible, that is) adding this perhaps-nonsensical rule doesn't seem like a big deal to me.
4) IMO, this rule is a good argument for not trying to adhere strictly to MISRA as written.
