Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There is no special treatment of main in the major C compilers, the only "magic" thing the compiler does is including the CRT startup object file in the link, which defines _start as a function ultimately calling main, and having the default linker script set the address of "_start" as the executable entry point.

You can pass -nostdlib to gcc to disable linking the CRT startup object (or use ld directly) and you can pass --default-script /dev/null to ld to disable the linker script.

There is no need to declare main or check arguments or return types since in C arguments are both pushed and popped by the caller and the language provides no typing guarantees and thus there is no problem in calling functions with mismatched argument or return type declarations.



Yes there is. I've demonstrated this in a sibling (or rather, cousin) comment, but in short, you can happily not return a value in main even if its type is "int main(void)". Try that with another function, and the compiler should at least warn. This might not be a special case of code generation, but it is a special case of error handling at least.


Not quite true: there’s the weird thing where gcc on i*86 will align the stack on entry to a function called main but not any other.

  $ gcc -m32 -O2 -fno-pie -fno-asynchronous-unwind-tables -fomit-frame-pointer -S -masm=intel -xc -o - -
  int foo(void); int main(void) { return foo(); }
  ^D
   .file "<stdin>"
   .intel_syntax noprefix
   .text
   .section .text.startup,"ax",@progbits
   .p2align 4
   .globl main
   .type main, @function
  main:
   push ebp
   mov ebp, esp
   and esp, -16
   call foo
   leave
   ret
   .size main, .-main
   .ident "GCC: (GNU) 11.1.0"
   .section .note.GNU-stack,"",@progbits
It doesn’t do that if you set the historical stack alignment, though (-mpreferred-stack-boundary=2), or if you name the function anything else but main (it even does a tail call). Presumably it’s trying to (somewhat) recover from the time when the GCC authors accidentally the SysV i386 ABI[1,2].

[1]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 [2]: https://stackoverflow.com/a/49397524




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: