The question you are asking is really two questions, not one. Most replies so far have tried to cover the entire thing with a generic blanket "this is K&R style" answer, while, in fact, only a small part of it has anything to do with what is known as K&R style (unless you see the entire C language as "K&R-style" in one way or another :)
The first part is the strange syntax used in the function definition
int func(p, p2)
void *p;
int p2; /* <- optional in C89/90, but not in C99 */
{
return 0;
}
This one is actually a K&R-style function definition. Other answers have covered this pretty well. And there's not much to it, actually. The syntax is deprecated but still fully supported even in C18 (except for "no implicit int" rule in C99 or later, meaning that in C99 you can't omit the declaration of p2).
The second part has little to do with K&R-style. I refer to the fact that the function can be called with "swapped" arguments, i.e. no parameter type checking takes place in such a call. This has very little to do with K&R-style definition per se, but it has everything to do with your function having no prototype. You see, in C, when you declare a function like this
int foo();
it actually declares a function foo that takes an unspecified number of parameters of unknown type. You can call it as
foo(2, 3);
and as
j = foo(p, -3, "hello world");
and so on (you get the idea);
Only the call with proper arguments will "work" (meaning that the others produce undefined behavior), but it is entirely up to you to ensure its correctness. The compiler is not required to diagnose the incorrect ones, even if it somehow magically knows the correct parameter types and their total number.
Actually, this behavior is a feature of C language. A dangerous one, but a feature nevertheless. It allows you to do something like this:
void foo(int i);
void bar(char *a, double b);
void baz(void);
int main()
{
void (*fn[])() = { foo, bar, baz };
fn[0](5);
fn[1]("abc", 1.0);
fn[2]();
}
i.e. mix different function types in a "polymorphic" array without any typecasts (variadic function types can't be used here, though). Again, the inherent dangers of this technique are quite obvious (I don't remember ever using it, but I can imagine where it can be useful), but that's C after all.
Finally, the bit that links the second part of the answer to the first. When you make a K&R-style function definition, it doesn't introduce a prototype for the function. As far as function type is concerned, your func definition declares func as
int func();
i.e. neither the types nor the total number of parameters are declared. In your original post, you say, "... it seems to specify is how many params it uses ...". Formally speaking, it doesn't! After your two-parameter K&R-style func definition, you still can call func as
func(1, 2, 3, 4, "Hi!");
and there won't be any constraint violation in it. (Normally, a quality compiler will give you a warning).
Also, a sometimes overlooked fact is that
int f()
{
return 0;
}
is also a K&R-style function definition that does not introduce a prototype. To make it "modern" you'd have to put an explicit void in the parameter list:
int f(void)
{
return 0;
}
Finally, contrary to popular belief, both K&R-style function definitions and non-prototyped function declarations are fully supported in C99 and beyond (up to C18, but not in C23). The former has been deprecated since C89/90, if I remember correctly. C99 requires the function to be declared before the first use, but the declaration is not required to be a prototype. The confusion apparently stems from the popular terminological mix-up: many people call any function declaration "a prototype", while, in fact, "function declaration" is not the same thing as "prototype".
Note that C23 will change the rules. The K&R style function definition will no longer be standard C. Further, a function declaration such as extern int func(); will declare a function prototype equivalent to extern int func(void); — just as in C++. And a function definition such as int func() { … } will define a prototype for the function.
