main() ohne Parameter?

Das Schreiben der Funktion int main() - also ohne Parameter - ist erlaubt und vollkommen OK.

Doch wie kann das sein? C kennt kein Function-Overloading und wir wissen doch, dass main eigentlich so aussieht:
int main(int argc, char** argv);

(Ja, mir ist bekannt, dass int main(int argc, char* argv[]); schöner aussieht, aber die Zeiger - auf - Zeiger - Version entspricht mehr der Abbildung auf die CPU.)

Da haben wir einen lustigen Seiteneffekt der Sprache C entdeckt. Denn wir können eine Funktion mit mehr Parametern aufrufen, als in ihrer Deklaration angegeben ist.

Folgende beiden Beispiele sollten ohne Fehler kompilieren und ausführbar sein

 /* test1.c */
 int test();
 
 int test(int a, int b)
 {
   return a + b;
 }
 
 int main()
{
  return test(42, 24);
}

 /* test2.c */
 int test();
 
 int test()
 {
   return 0;
 }
 
 int main()
{
  return test(42, 24);
}

Dazu braucht es also kein kompliziertes Name-mangling wie in C++, sondern eine Aufrufkonvention, die es erlaubt dieses Feature korrekt in die Maschinensprache zu übersetzen. Und das stellt C (auf allen mir bekannten Plattformen) sicher.

main ist auf den meisten Systemen ja nicht wirklich der originale Startpunkt eines Programms (auch wenn das gerne behauptet wird). Es ist nur die für den Programmierer sichtbare Start-Funktion. Jede Plattform hat ihre native Startprozedur, die die Umgebung initialisiert und dann erst main() aufruft.

 extern "C" int main();
 
 void real_native_entry_point()
 {
   int argc;
   char** argv;
   int return_value;
   
   ... /* load values from native platform interface */
  
  return_value = main(argc, argv);
  
  ... /* native clean-up of process and exit code handling */
}

Das ist vor allem bei C++ lebenswichtig. Denn wo werden denn sonst die Konstruktoren von globalen Objekten aufgerufen?
Das passiert ebenfalls vor main und deren Zerstörung setzt entsprechend ein, wenn main zurückkehrt, oder per C-API [exit()](http://www.cplusplus.com/reference/cstdlib/exit/) aufgerufen wird.

Und ganz nebenbei erklärt sich jetzt auch, warum die cdecl Aufrufkonvention auf X86 die Parameter in umgekehrter Reihenfolge auf den Stack PUSHt, denn der Stack wächst im Adressraum von oben nach unten und der zuletzt gePUSHte Parameter legt den Beginn des Stack-Frames einer Funktion fest.

test(1, 2, 3, 4, 5); sieht in Assembler dann in etwa so aus:

PUSH 5
PUSH 4
PUSH 3
PUSH 2
PUSH 1
CALL test
ADD ESP, 20   ; 5 * 4 bytes on 32 bit systems

Heute klingt das für mich alles logisch … doch als ich noch mit PASCAL arbeitete, wo Parameter in genau der Reihenfolge auf den Stack wanderten, wie es im Quelltext beschrieben war, da war C für mich unnötig kompliziert und ‘seltsam’ aufgebaut.

Und das war auch leider mit ein Grund, warum ich mich von C lange fern gehalten hatte.

… hätte mir das doch jemand früher erklärt …