Conflict between implicit declaration and varargs function

Question

Can anyone confirm what the standard says about the default return type of vararg function. I was compiling the following code:

int main()
{
    maw(32,3,95,38,20,15);
    return 0;
}

int maw(int a,int b,...)
{
    int *p=&b,i=0;
    while(i++<a)
       printf("\t%d",*p++);
    return 0;
}

but it gave error:

foo.c:9: error: conflicting types for ‘maw’
foo.c:10: note: a parameter list with an ellipsis can’t match an empty parameter name list declaration
foo.c:4: error: previous implicit declaration of ‘maw’ was here

but if during the definition of maw, if I mention it as void maw(int a, int b, ...) the compilation is quite fine.

I can make out from this that the default return type of vararg function is probably not int.

What does the standard say in this regard? Can anybody confirm it for me?

Answer 1

Declare maw() before main(), or prototype it before main(). Functions return the types that you assign to them, regardless of arguments (variadic or not).

Answer 2

The problem is that you're calling the function before defining it, and not including a declaration. If you add a line like this:

int maw(int a, int b, ...);

Before your main() function, you'll be fine. The default ("implcit") is to assume a function returns int, and has an empty argument list. It's bad form to rely on the implicit declaration, you should declare all functions explicitly.

Answer 3

It's nothing to do with the return type - it's the fact that you declared it at all. Put a declaration:

int maw(int a,int b,...);

before your use of the function in main()

Answer 4

Add the declaration

int maw(int a,int b, ...);

before your main() function.

Currently, the call you make within your main() function implicitly defines maw(), that is, the compiler "guesses" what maw()'s return type is based on the information it is given within main(). If you declare maw() before it is called, you will not have this problem.

Answer 5

The other answers are correct, about putting the function prototype first.

Additionally, to be portable, do not access the ... arguments by using a direct pointer to the last (non-vararg) argument, because then you have to care about the alignment and stack direction of your target platform. Instead, use <stdarg.h> and the va_* macros for working with varargs.

Answer 6

hi guyz thanks for reply. I know that if I just standrized the code it will run perfectly.I hv done it.There is no problem with that. My point is what is the problem with this code.It should have run perfectly. Does'nt a code like this run without any error

int main() {

abc(); ..... return 0; }

abc() { ....... }

The problem is coming when a variable argument function is being used. I know what the standard say for default declration of the function. Hope you take my point .

Answer 7

As every answer (so far) has said: to avoid the errors, declare the function before its use, and as Chris Jester-Young points out, use the standard mechanisms for accessing the variadic arguments or suffer the pains of Undefined Behavior.

In this example, it is not that the declaration before use in this case is required because of the function's return type, but rather because it does not match the default signature for an undeclared function: int u(); that is, a function taking unspecified arguments returning an int. Specifically, the actual definition int maw(int,int,...) is inconsistent with different from the assumed declaration int maw() which causes GCC to say "conflicting types for ‘maw’".

Your second example

int main() {
  abc(); ..... return 0; 
}
abc() { ....... }

works because the later definition of abc doesn't contradict the default signature assumed when its first call was encountered. But just because it works doesn't make it good form because you get almost no type safety from the default signature.

Access to the variadic arguments (the ones matching the ...) really should be done through the standard mechanisms of stdarg.h, unless you are implementing a compiler and are the author of that compiler's stdarg.h. For instance, on some architectures those arguments may not even be passed on the stack, but they can still be located by the macros from stdarg.h.

Edit: I reworded the second paragraph to say what I meant in a different, and I hope clearer, way.

The compiler needs to know that the function is variadic before the first call because on some architectures, it might be required to pass the variadic parameters differently than normal parameters. That is especially true of certain register-window RISK architectures, and those that might pass the first 2 ints and first 2 floats in registers, but must put all variadics on the stack even if there is room in the regsisters.

A similar declare before use situation exists for functions that do not use the cdecl calling convention. You will usually run into this when linking modules written in Pascal or FORTRAN with modules written in C. However, many of the Windows API functions exported by the core DLLs assume a calling convention named stdcall and if the compiler were to use a cdecl style call, the program would crash (and the whole machine on Windows 9x or earlier).