The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT, and of course completely irrelevant because you can make that mistake regardless of what the header says.
Parameters in headers are just documentation, by definition. Documentation can be wrong however you write it, but in general it helps to have it instead of not. Would you seriously argue that function parameters should not be given names in documentation?
> The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT
Actually if you look at the patch to fix this issue, they swap the identifiers in the declarator. Of course when something like this happens, you're free to choose whether the definition or the callers should be changed.
That's the function definition, not its declaration. It's pre-ANSI C, so that semicolon can mislead. I didn't bother to grab the source to check whatever the header said (or, heh, didn't say, per OpenBSD convention), but I'm going to assume it was correct.
It amuses me greatly that we're sitting here arguing over the minutiae of coding standards when this thing is still written in K&R syntax.
But regardless: whatever the header said, it wouldn't have affected this bug, which was just a straightforward transpose thing between compatible types. People get memcpy() reversed all the time too, and frankly I don't know if I've ever looked at its function declaration in a header.
The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT, and of course completely irrelevant because you can make that mistake regardless of what the header says.
Parameters in headers are just documentation, by definition. Documentation can be wrong however you write it, but in general it helps to have it instead of not. Would you seriously argue that function parameters should not be given names in documentation?