Naming the parameters in a prototype declaration should never be necessary, and is often unwise, because these names can be affected by macro definitions.
Although the scope of an identifier in a function prototype begins at its declaration and ends at the end of that function's declarator, this scope is ignored by the preprocessor. Consequently, an identifier in a prototype having the same name as that of an existing macro is treated as an invocation of that macro.
Safeguarding parameter names is particularly critical in standard and system headers where the user expects to be able to include the header and have only the function names visible.
Noncompliant Code Example
This noncompliant code example,
generates an error, because the prototype, after preprocessing, becomes
Perhaps more surprising is what happens if status is defined:
Then the resulting prototype is
which is syntactically correct but semantically quite different from the intent.
To protect an API's header prototypes from such misinterpretation, the developer must write them to avoid these surprises. Possible solutions include not using identifiers in prototypes, as in this example:
Another solution is to comment them out, as in this example:
Comments are converted to a single whitespace character in translation phase two.
Failure to protect header prototypes from misinterpretation can result in type errors in the program.