What is the purpose of such a function ?

[Razvan]

Hi!





What is the purpose of such a function ?


int function(void)
{

return 1;
}

It seems to be completely equivalent with


int function()
{

return 1;
}

Is its behaviour different on a C versus a C++ compiler ?



Regards,
Razvan

 

[Dan Pop]

What is the purpose of such a function ?

int function(void)
{
return 1;
}

It seems to be completely equivalent with

int function()
{
return 1;
}

Is its behaviour different on a C versus a C++ compiler ?

Yes. On a C compiler, the latter is an old style function definition,
that doesn't provide a prototype for the function:

fangorn:~/tmp 183> cat test.c
int function() { return 0; }

int main() { return function(2, 3); }
fangorn:~/tmp 184> gcc test.c
fangorn:~/tmp 185> g++ test.c
test.c: In function `int main()':
test.c:1: error: too many arguments to function `int function()'
test.c:3: error: at this point in file

The original version has identical semantics under both C and C++.

Dan

 

[kal]

What is the purpose of such a function ?

int function(void)
{

return 1;
}

It seems to be completely equivalent with

int function()
{

return 1;
}

Is its behaviour different on a C versus a C++ compiler ?

I think so.

In C: "int f(void);" delcares a function with NO parameters
returning an int. "int f();" declares a function with no
parameter SPECIFICATION returning an int.

 

[Dan Pop]

In C: "int f(void);" delcares a function with NO parameters
returning an int. "int f();" declares a function with no
parameter SPECIFICATION returning an int.

Well, it still specifies something: that the unknown number of parameters
of unknown types is fixed, i.e. f() cannot be a variadic function.

Dan

 

[S.Tobias]

Well, it still specifies something: that the unknown number of parameters
of unknown types is fixed, i.e. f() cannot be a variadic function.

It seems (by experiment) that you can make both f(2,3) and f(2,3,4)
calls in the same function main().
Then is it possible (or was it in the "old style") to define:
int f(int n, ...) { /*...*/ }
and declare in the header:
int f();
?

 

[Dan Pop]

It seems (by experiment) that you can make both f(2,3) and f(2,3,4)
calls in the same function main().

At least one of them invokes undefined behaviour.

Then is it possible (or was it in the "old style") to define:
int f(int n, ...) { /*...*/ }
and declare in the header:
int f();
?

The ellipsis thing didn't exist at all pre-ANSI. On implementations
supporting the <varargs.h> interface, you'd declare it as

int f();

and define it like this:

#include <varargs.h>

int f(va_alist)
va_dcl /* no semicolon */
{
...
}

The actual mechanism for accessing the parameter list was relatively
similar to the one provided by <stdarg.h>.

Dan

 

[S.Tobias]

Could you, please, give me the place in the Standard that supports this?

I'm not challenging your claim at all. I've checked on-line como
and it refuses to take
int f();
int f(int i, ...) { return 0; }
both in C90 and C99 mode.
But OTOH I've searched through the Standard and the only explicit
statement about this I could find is a note in 7.15.1.4#6 in an
example for va_start macro:
[...]
void f1(int n_ptrs, ...)
{
[...]
}
Each call to f1 is required to have visible the definition of the
function or a declaration such as
void f1(int, ...);
But AFAIK examples are not normative.

At least one of them invokes undefined behaviour.

What I meant is that gcc didn't protest. I thought that the compiler
might be wise enough to notice different number of arguments, if it
were an issue. Since it didn't (neither did como btw), I thought it
might consider f() variadic, which led me to next question.

The ellipsis thing didn't exist at all pre-ANSI. On implementations
supporting the <varargs.h> interface, you'd declare it as

[snip]

Thank you!

 

[Ralmin]

Could you, please, give me the place in the Standard that supports this?

What about 6.5.2.2 "Function Calls", paragraph 6?

"If the expression that denotes the called function has a type that
does not include a prototype, the integer promotions are performed
on each argument, and arguments that have type float are promoted
to double. These are called the default argument promotions. If the
number of arguments does not equal the number of parameters, the
behavior is undefined. If the function is defined with a type that
includes a prototype, and either the prototype ends with an
ellipsis (, ...) or the types of the arguments after promotion are
not compatible with the types of the parameters, the behavior is
undefined."

This paragraph makes it undefined behaviour to call a variadic function
through an unprototyped declaration.

 

[Jack Klein]

Could you, please, give me the place in the Standard that supports this?

It is not easy to parse it out, but it is in C99 6.5.2.2, P6 which
talks about calls to functions that do not have a prototype (although
in C99 they must have at least a declaration):

[begin quote]

If the expression that denotes the called function has a type that
does not include a prototype, the integer promotions are performed on
each argument, and arguments that have type float are promoted to
double. These are called the default argument promotions. If the
number of arguments does not equal the number of parameters, the
behavior is undefined. If the function is defined with a type that
includes a prototype, and either the prototype ends with an ellipsis
(, ...) or the types of the arguments after promotion are not
compatible with the types of the parameters, the behavior is
undefined.

[end quote]

So if you call a function without a prototype in scope and it is
variadic (i.e., it is defined with an argument list ending in ", ...",
the behavior is specifically undefined.

I'm not challenging your claim at all. I've checked on-line como
and it refuses to take
int f();
int f(int i, ...) { return 0; }
both in C90 and C99 mode.
But OTOH I've searched through the Standard and the only explicit
statement about this I could find is a note in 7.15.1.4#6 in an
example for va_start macro:
[...]
void f1(int n_ptrs, ...)
{
[...]
}
Each call to f1 is required to have visible the definition of the
function or a declaration such as
void f1(int, ...);
But AFAIK examples are not normative.

At least one of them invokes undefined behaviour.

What I meant is that gcc didn't protest. I thought that the compiler
might be wise enough to notice different number of arguments, if it
were an issue. Since it didn't (neither did como btw), I thought it
might consider f() variadic, which led me to next question.

Remember, the standard places no requirements at all in cases of
undefined behavior. An implementation is allowed, but not required,
to emit a diagnostic for undefined behavior. But it is also allowed,
but not required, to emit a diagnostic for any reason at all.

i.e.:

# ds2kc welldefined.c
Death Station 2000 C2009 Compiler Version 1.0
compiling welldefined.c...
Lovely weather we're having today, isn't it?
0 errors
#

The wording in C89/90 was similar, although it had text allowing for
implicit declaration of functions returning int.

 

[Razvan]

What is the purpose of such a function ?

Yes. On a C compiler, the latter is an old style function definition,
that doesn't provide a prototype for the function:

fangorn:~/tmp 183> cat test.c
int function() { return 0; }

int main() { return function(2, 3); }
fangorn:~/tmp 184> gcc test.c
fangorn:~/tmp 185> g++ test.c
test.c: In function `int main()':
test.c:1: error: too many arguments to function `int function()'
test.c:3: error: at this point in file

The original version has identical semantics under both C and C++.

You are able to compile the code with the C compiler (gcc) but
not with the C++ compiler (g++).

That means:
1. int f(void)
Under both C and C++ languages it is a function that takes no
parameters and return an int;

2. int f()
in C - a function that takes ANY number of parameters;
in C++ - a function that takes NO parameters.

So, if you want to write a function that takes no parameters
that is valid C & C++ code you should write:

int f(void)



Thanks,
Razvan

 

[Dan Pop]

Could you, please, give me the place in the Standard that supports this?

Since I have already located it for another thread, it's quite easy.

I'm not challenging your claim at all. I've checked on-line como
and it refuses to take
int f();
int f(int i, ...) { return 0; }
both in C90 and C99 mode.

It is right, as f is not declared with compatible types in the two
declarations:

6.7.5.3

15 For two function types to be compatible, both shall specify
compatible return types. Moreover, the parameter type lists,
if both are present, shall agree in the number of parameters and
in use of the ellipsis terminator; corresponding parameters shall
have compatible types. If one type has a parameter type list
and the other type is specified by a function declarator that
is not part of a function definition and that contains an empty
identifier list, the parameter list shall not have an ellipsis
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
terminator and the type of each parameter shall be compatible
^^^^^^^^^^
with the type that results from the application of the default
argument promotions...

Contrary to what other people said, this is not a case of undefined
behaviour: a diagnostic is required, because there are two conflicting
declarations for the same identifier, at file scope.

You'd have undefined behaviour if the declaration and definition were
in different translation units. Typical example:

int printf();

int main()
{
printf("hello world\n");
return 0;
}

What I meant is that gcc didn't protest. I thought that the compiler
might be wise enough to notice different number of arguments, if it
were an issue. Since it didn't (neither did como btw), I thought it
might consider f() variadic, which led me to next question.

Undefined behaviour doesn't require a diagnostic. The compiler didn't
have a prototype for f() in scope, so it had nothing to check the function
calls against. What it did see is that f(2, 3) is compatible with the
declaration of f() and that f(2, 3, 4) is compatible with the declaration
of f(), so there was nothing to complain about. No attempt to check
whether the two function calls were consistent.

More sophisticated code checkers would build a prototype from the
first call of f(): int f(int, int) and check all other calls of f()
against this prototype. Allowed, but not required by the standard.

This was quite popular in the pre-ANSI days, when prototypes didn't
exist at all. The down side of this technique was that it didn't
handle the unrecognised variadic functions calls well (they were
declared like ordinary functions, back then), so you had to somehow
inform the tool that it is dealing with a variadic function.

Dan

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

Well, it still specifies something: that the unknown number of parameters
of unknown types is fixed, i.e. f() cannot be a variadic function.

int f(); declares function that can be called with any number of
arguments with any type.

 

[J. J. Farrell]

int f(); declares function that can be called with any number of
arguments with any type.

No. It declares a function with a fixed number of parameters of
fixed types, but it doesn't tell you what the number or types are.

 

[Dan Pop]

int f(); declares function that can be called with any number of
arguments with any type.

If that were true, f(1), f(1, 2) and f(1, 2, 3) could ALL be correct calls
of f(). In fact, at most one of them can be correct. For all of them to
be correct, f has to be declared like this:

int f(int, ...);

Dan

 

[CBFalconer]

.... snip ...


If that were true, f(1), f(1, 2) and f(1, 2, 3) could ALL be
correct calls of f(). In fact, at most one of them can be correct.
For all of them to be correct, f has to be declared like this:

int f(int, ...);

I have a slight problem seeing how that first argument of 1 can be
used at the function end to discriminate between the three calls
Now if you had suggested f(1), f(2,1), f(3,2,1) as the
possible calls, I could be convinced.

 

[Dan Pop]

I have a slight problem seeing how that first argument of 1 can be
used at the function end to discriminate between the three calls
Now if you had suggested f(1), f(2,1), f(3,2,1) as the
possible calls, I could be convinced.

The information about the number of arguments need not be passed as an
explicit function argument. I'll let you figure out other ways of
conveying it...

Dan

 

[Eric Sosman]

... snip ...



I have a slight problem seeing how that first argument of 1 can be
used at the function end to discriminate between the three calls
Now if you had suggested f(1), f(2,1), f(3,2,1) as the
possible calls, I could be convinced.

int how_many_f_args;
int f(int arg1, ...) {
int i;
va_list ap;
printf ("Arg 1 = %d\n", arg1);
va_start (ap, arg1);
for (i = 2; i <= how_many_f_args; ++i)
printf ("Arg %d = %d\n", i, va_arg(ap, int));
va_end (ap);
return 42;
}
...
how_many_f_args = 1; f(1);
how_many_f_args = 2; f(1, 2);
how_many_f_args = 3; f(1, 2, 3);

Bad practice, I'd say, but certainly possible.

 

[Dan Pop]

int how_many_f_args;
int f(int arg1, ...) {
int i;
va_list ap;
printf ("Arg 1 = %d\n", arg1);
va_start (ap, arg1);
for (i = 2; i <= how_many_f_args; ++i)
printf ("Arg %d = %d\n", i, va_arg(ap, int));
va_end (ap);
return 42;
}
...
how_many_f_args = 1; f(1);
how_many_f_args = 2; f(1, 2);
how_many_f_args = 3; f(1, 2, 3);

Bad practice, I'd say, but certainly possible.

There are more interesting ways, based on conventions between the two
parties. Two that would make my example work are:

1. The first invocation of f() takes one argument, the second two and so
on. f() has a static invocation counter that is also its return value.

2. The last argument of f() specifies the length of the variable part
of the *next* call of f(). The first call has no variable part.
The function returns the number of parameters it was expecting
when invoked.

Of course, I'm not recommending them to anyone, merely pointing out ways
of making my arbitrary example work.

Dan