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

In <15f19d61.0406220104.6ea654b8@posting.google.com> mihai11@mailcity.com (Razvan) writes:

>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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

mihai11@mailcity.com (Razvan) wrote in message news:<15f19d61.0406220104.6ea654b8@posting.google.com>...

> 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.

In <a5da4cc1.0406220850.7b21facd@posting.google.com> k_amir7@yahoo.com (kal) writes:

>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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Dan Pop <Dan.Pop@cern.ch> wrote:
> In <a5da4cc1.0406220850.7b21facd@posting.google.com> k_amir7@yahoo.com (kal) writes:

> >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.

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();
?

-- 
Stan Tobias

In <2jrat3F14k3gpU1@uni-berlin.de> "S.Tobias" <sNOiSPAMt@amu.edu.pl> writes:

>Dan Pop <Dan.Pop@cern.ch> wrote:
>> In <a5da4cc1.0406220850.7b21facd@posting.google.com> k_amir7@yahoo.com (kal) writes:
>
>> >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.
>
>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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Dan Pop <Dan.Pop@cern.ch> wrote:
> >> of unknown types is fixed, i.e. f() cannot be a variadic function.

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.

> >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.

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.

> >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
[snip]

Thank you!

-- 
Stan Tobias

"S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote:
> Dan Pop <Dan.Pop@cern.ch> wrote:
> > >> of unknown types is fixed, i.e. f() cannot be a variadic function.
>
> 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.

-- 
Simon.

On 22 Jun 2004 21:22:55 GMT, "S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote
in comp.lang.c:

> Dan Pop <Dan.Pop@cern.ch> wrote:
> > >> of unknown types is fixed, i.e. f() cannot be a variadic function.
> 
> 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.
> 
> > >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.
> 
> 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.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

> >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++.


       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

Jack Klein <jackklein@spamcop.net> wrote:
> On 22 Jun 2004 21:22:55 GMT, "S.Tobias" <sNOiSPAMt@amu.edu.pl> wrote
> in comp.lang.c:
> > Dan Pop <Dan.Pop@cern.ch> wrote:

> > > >> of unknown types is fixed, i.e. f() cannot be a variadic function.
> > 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.

Ah, yes!  I had to read it a few times to understand it correctly!

It's still worth adding that you should not define a variadic function
without a prototype: "If a function that accepts a variable number
of arguments is defined without a parameter type list that ends
with the ellipsis notation, the behavior is undefined." (6.9.1#8).

Thanks a lot!


> # 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
> #

:-)

-- 
Stan Tobias

In <2jrm9fF14r3roU1@uni-berlin.de> "S.Tobias" <sNOiSPAMt@amu.edu.pl> writes:

>Dan Pop <Dan.Pop@cern.ch> wrote:
>> >> of unknown types is fixed, i.e. f() cannot be a variadic function.
>
>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;
    }

>> >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.
>
>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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

On Tue, 22 Jun 2004 17:08:37 +0000, Dan Pop wrote:

> In <a5da4cc1.0406220850.7b21facd@posting.google.com> k_amir7@yahoo.com (kal) writes:
> 
>>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.
int f(); declares  function that can be called with any number of
arguments with any type.

Nils O. Sel�sdal <NOS@Utel.no> wrote in message news:<pan.2004.06.23.21.07.53.177589@Utel.no>...
> On Tue, 22 Jun 2004 17:08:37 +0000, Dan Pop wrote:
> 
> > In <a5da4cc1.0406220850.7b21facd@posting.google.com> k_amir7@yahoo.com (kal) writes:
> > 
> >>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.
>
> 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.

In <pan.2004.06.23.21.07.53.177589@Utel.no> =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?= <NOS@Utel.no> writes:

>On Tue, 22 Jun 2004 17:08:37 +0000, Dan Pop wrote:
>
>> In <a5da4cc1.0406220850.7b21facd@posting.google.com> k_amir7@yahoo.com (kal) writes:
>> 
>>>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.

>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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Dan Pop wrote:
> <NOS@Utel.no> writes:
> 
.... snip ...
> 
>> 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, ...);

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.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In <40DAD5F6.42F0B6A7@yahoo.com> CBFalconer <cbfalconer@yahoo.com> writes:

>Dan Pop wrote:
>> <NOS@Utel.no> writes:
>> 
>... snip ...
>> 
>>> 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, ...);
>
>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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

CBFalconer wrote:
> Dan Pop wrote:
> 
>><NOS@Utel.no> writes:
>>
> 
> ... snip ...
> 
>>>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, ...);
> 
> 
> 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.

-- 
Eric.Sosman@sun.com

In <40DAF363.6010109@sun.com> Eric Sosman <Eric.Sosman@sun.com> writes:

>CBFalconer wrote:
>> Dan Pop wrote:
>> 
>>><NOS@Utel.no> writes:
>>>
>> 
>> ... snip ...
>> 
>>>>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, ...);
>> 
>> 
>> 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.

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
-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de