Rejecting "void f(const void);"?

In all of clang, gcc, and comeau, some sort of error is given for a
declaration like "void f(const void);". However, as far as I can
tell, it's perfectly valid code (although mostly worthless, since the
declared function can't be called or defined). Is there some reason
for rejecting this that I'm missing?

Here are a few similar tests: "const void f(void)", "const void
f(void) {}", "const void f(void); void g(void) {f();}". The first
test is legal code, the second and third are not, as far as I can
tell. clang incorrectly allows the second and third tests, gcc
incorrectly allows the third test, and comeau incorrectly rejects the
first test. (Although note that clang doesn't have any checks for
incomplete return types yet.)

-Eli

FWIW I agree, I can't see any reason to reject this admittedly useless
type qualifier. While void isn't a valid lvalue, from my reading it just
means that the const is useless - not incorrect.

Someone could conceivably raise it on the C reflector though.

-eric

Eli Friedman wrote:-

In all of clang, gcc, and comeau, some sort of error is given for a
declaration like "void f(const void);". However, as far as I can
tell, it's perfectly valid code (although mostly worthless, since the
declared function can't be called or defined). Is there some reason
for rejecting this that I'm missing?

See Defect Report #017,
part 14. Intent seems to be to give implementations license to reject.

Neil.

Yeah... section J.2 says "A storage-class specifier or type qualifier
modifies the keyword void as a function parameter type list
(6.7.5.3)." is undefined behavior. That said, there's nothing in the
referred-to section that actually makes it illegal. So I'd still like
to try and get some clarification.

-Eli

I just found Defect Report #084;
if the answer hasn't changed since the question was originally posed,
"void a(const void);" constitutes undefined behavior.