Function definition with empty parameters list

[candide]

Does the following code


/* -------------------------- */
#include <stdio.h>

/* Function definition with empty parameters list hence test() has no
parameter */
void test()
{
printf("test\n");
}

int main(void)
{
/* The number of arguments doesn't match the number of parameters */
test(42);
return 0;
}
/* -------------------------- */

contain an undefined behavior ?

 

[jameskuyper]

Does the following code


/* -------------------------- */
#include <stdio.h>

/* Function definition with empty parameters list hence test() has no
parameter */
void test()
{
printf("test\n");
}

int main(void)
{
/* The number of arguments doesn't match the number of parameters */
test(42);
return 0;
}
/* -------------------------- */

contain an undefined behavior ?

A declaration that does not specify any parameters, not even "void",
is not normally considered to qualify as a function prototype, which
is required to identify the number and types of the function's
parameters. However, it has been argued that such a declaration, when
it occurs as part of the function definition, which is visible in the
same scope as the function call, does qualify as a prototype, becaue,
as part of a function definition, it does clearly identify the number
of parameters as being 0.

Rather than reopening that controversy, I'll just point out that the
behavior is undefined, whether or not the definition of test()
qualifies as a prototype.

If it is a prototype, then 6.5.2.2p2 applies: "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." This
is constraint violation, for which a diagnostic is required; an
implementation is not required to accept such code, but if it chooses
to do so, the standard does not define what the behavior of the
resulting program will be.

If it is not a prototype, then 6.5.2.2p6 applies: "If the expression
that denotes the called function has a type that does not include a
prototype ... If the number of arguments does not equal the number of
parameters, the
behavior is undefined."

 

[Tim Rentsch]

Does the following code


/* -------------------------- */
#include <stdio.h>

/* Function definition with empty parameters list hence test() has no
parameter */
void test()
{
printf("test\n");
}

int main(void)
{
/* The number of arguments doesn't match the number of parameters */
test(42);
return 0;
}
/* -------------------------- */

contain an undefined behavior ?

Yes. The number of function arguments always must
match the number of parameters in the function's
definition. (Functions taking a variable number of
arguments have a different rule, but that's not the
case here.) If the function test() were defined
as 'void test(void) ...' then its type would include
a prototype and the call would require a diagnostic;
but test() is not so defined, and so the compiler is
not obliged to issue an error message. But it's still
undefined behavior, because the numbers of arguments
and parameters don't match.

 

[Tim Rentsch]

Does the following code


/* -------------------------- */
#include <stdio.h>

/* Function definition with empty parameters list hence test() has no
parameter */
void test()
{
printf("test\n");
}

int main(void)
{
/* The number of arguments doesn't match the number of parameters */
test(42);
return 0;
}
/* -------------------------- */

contain an undefined behavior ?

A declaration that does not specify any parameters, not even "void",
is not normally considered to qualify as a function prototype, which
is required to identify the number and types of the function's
parameters. However, it has been argued that such a declaration, when
it occurs as part of the function definition, which is visible in the
same scope as the function call, does qualify as a prototype, becaue,
as part of a function definition, it does clearly identify the number
of parameters as being 0.

Rather than reopening that controversy, [...]

This question is settled clearly and unambiguously by 6.5.2.2p8.
Note the final word, "declarator".

 

[James Kuyper]

Rather than reopening that controversy, [...]

> [Attempt to reopen that controversy]

As I said, I didn't want to reopen it; if you want to, find the most
recent rehash of that controversy, and post your answer as a response to
the most recently posted contrary argument.

 

[Tim Rentsch]

"An empty list in a function declarator that is part
of a function definition specifies that the function has no
parameters." - so void test() { ... } defines test as taking no
parameters.

"If the function is defined with a type that
does not include a prototype, and the types of the arguments after
promotion are not compatible with those of the parameters after
promotion, the behavior is undefined."

void test() is not a function prototype, so this paragraph applies.
Since 42 is of type int, and since int is not compatible with void,
the behaviour is indeed undefined.

This statement is misleading. There isn't a (void) parameter,
or any parameter. There isn't any sense in asking whether the
argument type is compatible with the parameter type, for there
is no parameter type against which to compare it. The number of
arguments doesn't match the number of parameters, and that by
itself causes undefined behavior.

"Moreover, the parameter type lists, if both are present, shall agree
in the number of parameters" - so it's a violation of a "shall"
requirement that is outside a constraint. Therefore, again, the
behaviour is undefined.

There are no parameter type lists for the function test() in
the above example code.

 

[Tim Rentsch]

Rather than reopening that controversy, [...]

[Attempt to reopen that controversy]

As I said, I didn't want to reopen it; if you want to, find the most
recent rehash of that controversy, and post your answer as a response
to the most recently posted contrary argument.

I wasn't trying to reopen the previous controversy, only
address the question of what happens in the particular case
raised by OP. My comments were on point in the context of
answering the OP's question, and that's all I was trying to
say.

Also, I ask that you refrain from paraphrasing my comments
as you have done above. Whether it was deliberate or not,
the re-statement distorted the meaning intended. I might
suggest a principle (meant for the group generally): don't
paraphrase/summarize text on the points being responded to.