Case 1:
void hello(void) { //something } int main() { hello(1); //error return 0; } Case 2:
int main(void) { //something return 0; } Execution:
./a.out something something //No error, Why? Why there is no error? main will not be able to take any arguments. So why it is possible to provide arguments from the command line?
Because the C compiler and the command line interpreter (or whatever is used to invoke your program) are different things.
The C language allows various ways how main () could be declared.
The command line interpreter will make any arguments available to the program. If the program ignores them, that's none of its business.
The command line interpreter doesn't even know that you used C to compile your program. On my computer, the program could be written in C, C++, Objective-C, Objective-C++, Swift, Fortran, Ada, and so on. Each of these compilers may or may not do things to accept commands from the command line.
Not checking the specification nor compiled result, it will cause no error because the C runtime will get the arguments and pass them to main(), but this type of main() will ignore the passed arguments, and if it is caller's duty to clean up the memory (stack) used as the arguments, it will cause no problems just as getting some arguments and not using them in the code.
This code won't emit errors in C:
void hello(); // in C, the compiler won't check arguments int main() { hello(1); //no error return 0; } void hello(void) { //something } 
main are cleaned off the stack by the function that calls main, which is a shim provided by the C library, and that function doesn't know or care how main was declared. This isn't special to main; this is the normal C calling convention for all functions. (Compiler extensions like __stdcall can change the convention. Bad Things will happen if you apply them to main--or to any other function called by the C library.)argv come from in the first place? The kernel loads it into memory along with the program, as part of the execve operation, and constructs an initial call frame that tells the C library's startup code where to find it. It's usually at the very top of the stack, but it doesn't have to be, and it's never deallocated.exit instead. See for instance the very end of sourceware.org/git/?p=glibc.git;a=blob;f=csu/libc-start.c .
Because ./a.out something something is not directly calling your main function. THe main function is being called by the c runtime library. The command line arguments are placed in a region somewhere on the stack (very beginning) by the loader/c runtime. It is upto you if you want to access these arguments or not.
Plus as pointed out in one of the comments as well at least one command line argument is always passed anyways (the name of the program ./a.out to be precise) - so you must have wondered about an error in that case as well.
Recall that ISO C specifies the two possible signatures of main: int main(void) and int main(int, char *[]) and the equivalent versions thereof, like int main(int, char **) because of array-to-pointer decay. This is covered more in detail here.
This question can be answered by considering the opposite question: how does the C runtime know what main to call? C doesn't have overload resolution! This is explained here. Briefly, the others are pushed but not accessed because there's no indication from C to do that.
When you compile your program using gcc program_name.c, compiler will report any possible compile time warning or error. Since the command line arguments are not passed at the compile time, compiler is unaware of it and program just ignore that arguments.
In case of hello, compiler knows the prototype of this function and expects no argument to be passed in its call and hence reports error in case of any argument passed to it.
argv[0]).mainis not the same kind of function ashello.main(float)generates only a warning, no error. And only with -Wall even.)