Why do we need return type and parameter type in funtion declarations?

I've been told we somehow need them so the compiler can continue onwards without having read the definition yet.

Somehow we need them in order for the program to work properly, to avoid conflicts between functions.

Please explain.

If you're going to have separate compilation, meaning that the call versus the definition of a function might be in separate source files, compiled at different times, perhaps months or years apart, you need to decide how information passed to and returned from the function is going to be coordinated.

Let's cover the return value first. Functions can be declared to return int, or double, or char *, or just about any of C's other types. (There are one or two exceptions, types which it's impossible to return, but they needn't concern us here.) But for any given ABI, different values get returned in different ways. Integers and pointers might get returned in a general-purpose processor register. Floating-point values might get returned in a floating-point register. Structures might get returned in some specially-designated memory area. In any case, the called function is going to do the returning, but the calling function (compiled separately) is going to do something with the returned value, so it has to know how to emit the right code to do that. And the only way for it to know (again, under C's separate-compilation model) is the function declaration that indicated the return type. If the calling code thought the function was going to return an int, but the called function actually returned a double, it just wouldn't work, because the called function would place its return value in the spot where return values of type double go, and the calling code would fetch a value from the place where return values of type int go, and it would get indeterminate garbage instead.

Now let's talk about the arguments passed to the function. Again, the mechanisms behind argument passing can take several forms, depending on the type(s) of the argument(s). Again, mismatches are easy, but can cause serious problems. If the programmers writing calling code could be relied on to always pass the correct number of arguments, and of the correct types, we wouldn't need function prototypes — and indeed, that's how C was for the first few years of its life. These days, however, that risk is generally considered as unacceptable, and function prototypes are considered mandatory — by the language standard, by compilers, and by most C programmers. (You might still find a few holdouts, grumbling that prototypes are newfangled or unnecessary, but they're basically an ignorable minority.)

There's a remaining wrinkle concerning "varargs" functions such as printf. Since they don't accept a fixed number of fixed-type arguments, they can't have a prototype that specifies the types of those arguments in advance. An ellipsis ("...") in a function prototype indicates variable arguments that (a) can't be enforced by the compiler but that (b) do have the default argument promotions performed on them, to provide a little more regularity (basically, small types like char and int promoted to int, and float promoted to double). Varargs functions, too, are generally consider old-school and risky if not downright dangerous, and are not recommended for new designs, unless perhaps if they follow the pattern of printf, meaning that the compiler can peek at the format string (if constant) and do the programmer the favor of double-checking the arguments.

The requirements here have been evolving ever since C was invented, and (as discussed in the comments) are still changing. If you have specific questions about what's legal and what's not, what works and what won't, you might want to ask them explicitly, but the answer may depend on which version of C we're talking about.

We can get a good picture of most of the issues just by looking at the standard sqrt function. Suppose you say

double x = sqrt(144);

Once upon a time, that was doubly wrong. Once upon a time, without a function declaration in scope, sqrt would be assumed to return int, meaning that this call wouldn't work, because sqrt actually returns a double. (The compiler would emit code to fetch an int and convert it to the double required by x, but this would be meaningless since there's no int actually returned by sqrt to convert.) But, there's a second problem: sqrt accepts a double argument, which this code doesn't pass, so sqrt wouldn't even receive the correct value to take the square root of.

So, once upon a time, you absolutely needed

extern double sqrt();

(which you probably got from <math.h>) to tell the compiler that sqrt returned a double, and it was your responsibility to call

double x = sqrt(144.);

or

double x = sqrt((double)144);

to cause a double value to be passed.

Today, if you call sqrt out of a clear sky (that is, without a declaration in scope), the compiler is more likely to complain that there's no prototype in scope — that is, it will not quietly assume that sqrt returns int. And if there is a declaration in scope, it will be the prototype declaration

extern double sqrt(double);

which explicitly says that sqrt expects one argument of type double. So, today, the code

double x = sqrt(144);

works fine — the compiler knows to implicitly convert the int value 144 to double before passing it to sqrt.

If you did something really wrong, like calling sqrt(44, 55), in the old days you'd get no complaints (and a very wrong answer), while today you'll get an error saying you've passed too many arguments.

This is probably a longer answer than you were looking for, but in closing, there are two final points to make:

1. No one would claim that any of this makes perfect sense, or is the way you'd design things from scratch, today. We're living (as ever) with a number of imperfect compromises between modernity and backwards compatibility.
2. The "guarantees" apparently promised by function prototypes — namely, that automatic argument conversions will be performed if possible, and that compile-time errors will be emitted for gross mismatches — are not absolute, and still depend on a certain amount of programmer care, namely to ensure that the prototypes (upon which everything depends) are actually correct. This generally means putting them in .h files, included both by the caller and the defining source file. See also this question exploring how those vital conventions might be enforced.

Because C Compilers compile code row from top to bottom. If you gonna use any function in your main function you have two ways to do that.

1. You can code your function first then use main(Compiler code row from top to bottom so it will figure out there is a function)
2. Like you do you can use parameters to say "Hey there is a function that i made i will use that later" to Compiler.

Example:

• Declaration without parameters. COMPILES.
• Declaration without parameters and either without type. COMPILES BUT WARNING.
• Call BEFORE definition (and no declaration). Compile error. ERROR.

Compiles perfectly (as @Vlad from Moscow pointed, neither parameters are needed in declaration):

  1 #include <stdio.h>
  2 
  3 int sum ();     // no parameters declaration (if also omit type int, will compile but with warning
  4 
  5 int main (void)
  6 {
  7         int numa = 2, numb = 3;
  8 
  9         printf ("Sum %d + %d = %d\n", numa, numb, sum ( numa, numb ));
 10 
 11         return 0;
 12 }
 13 
 14 int sum ( int numa, int numb )
 15 {
 16         return numa + numb;
 17 }

output:

./ftype_def_dec                    
Sum 2 + 3 = 5

type int of function ommited (compiled but with warning):

gcc -o ftype_def_dec ftype_def_dec.c
ftype_def_dec.c:3:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
sum ();
^
1 warning generated.

Does not compile (if you omit declaration in a function called in main() BEFORE it's DEFINITION [every detail [types & what/how it does explicited]]):

  1 #include <stdio.h>
  2 
  3 // int sum ();
  4 
  5 int main (void)
  6 {
  7         int numa = 2, numb = 3;
  8 
  9         printf ("Sum %d + %d = %d\n", numa, numb, sum ( numa, numb ));
 10 
 11         return 0;
 12 }
 13 
 14 int sum ( int numa, int numb )
 15 {
 16         return numa + numb;
 17 }

gcc -o ftype_def_dec ftype_def_dec.c
ftype_def_dec.c:9:44: error: implicit declaration of function 'sum' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        printf ("Sum %d + %d = %d\n", numa, numb, sum ( numa, numb ));
                                                  ^
1 error generated.

Because the compiler has to be able to know how your function can be called and used (i.e. what parameters it accepts and what its return type is (although the former can be omitted)) in other calling functions (such as in main).

As mentioned by another answer, the compiler will compile your program from top to bottom. Thus, when it reaches a given line in your program where you use your function, if you had not previously declared it, it would not know how to parse and compile that statement, and/or be able to detect if it consists of an error.

Take a simple example:

void square(int*);

int main(void) {
    
    int number = 4;
    
    number = square(number); // ERROR
    // correct usage would be:
    square(&number);
    return 0;
}

void square(int *num) {
    if (!num)
        return;
    *num *= *num;
}

However, if you had not declared square before main, the compiler would have no way of knowing what do with your call to square inside main, or which of the two calls was an error.

In other words, square is an undeclared identifier if you have not declared the function before calling it.

Just like you cannot do something like:

int main(void) {
    int x = 2;
    y = x + 5; // ERROR: undeclared identifier 'y'
    int y;
    return 0;
}

... because the compiler has no idea what y is by the time it reaches its first usage.