4 ms·

> Since I knew the target system is going to be 64bit Linux Knowing the target system makes a lot of these things quite a bit easier. I had really good luck i

> Since I knew the target system is going to be 64bit Linux Knowing the target system makes a lot of these things quite a bit easier. I had really good luck in college knowing our graphics teacher was using a 286. As a TA you pretty much can be a hardass or save time for the rest of the semester and just mark 100. Another early scenario was declaring main() as void in some embedded systems. I guess there was nothing to return to but it was still odd.

TazeTSchnitzel 9y ago
It's weird how compilers complain if main() is void, despite it not having to return anything if it's int.
- user5994461 9y ago
  You have to return something. If you don't, the exit code is the value that happened to be in memory at this point.
  - TazeTSchnitzel 9y ago
    Normally, yes. But main() is special and implicitly returns 0, for whatever reason.
    - user5994461 9y ago
      Absolutely not. You can look at a crashing programs and see the return code is a random value. You can also make a program that doesn't return anything and see that it's also a random value, though some compilers on some platforms might initialize that to zero.
      - TazeTSchnitzel 9y ago
        No, it's literally special-cased in the C standard.
        pjc50 9y ago
        Someone should tell the gcc maintainers then. int main() { int a = 12; } $ gcc maintest.c $ ./a.out $ echo $? 148
        TazeTSchnitzel 9y ago
        $ cat test.c int main(void) {int a = 12;} $ gcc-6 test.c -o test --std=c89; ./test; echo $? 162 $ gcc-6 test.c -o test --std=c99; ./test; echo $? 0 Must be a C99 thing.
        albinofrenchy 9y ago
        This isn't that conclusive of a test -- uninitialized memory is 0 relatively often.
        clarry 9y ago
        https://github.com/gcc-mirror/gcc/blob/4bec7283cda24b180ea7a01ae62214058a8e0020/gcc/c/c-decl.c#L9275 https://github.com/gcc-mirror/gcc/blob/4bec7283cda24b180ea7a...
        pjscott 9y ago
        Okay, that is conclusive. (And I'm pleasantly surprised by how readable GCC's source code is.)
        kaushiks 9y ago
        This has nothing to do with memory. The x86_64 ABI returns values from functions in the RAX register.
        albinofrenchy 9y ago
        Sure; same point applies though -- just because 0 happens to be in RAX doesn't mean it's defined behavior.
  - clarry 9y ago
    N1256 5.1.2.2.3 p1: If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
    - user5994461 9y ago
      main() is __cdecl__ or __stdcall__ on the major platforms. That calling convention on x86 specifies that the return value is red from the EAX register. So, when your main() function exits, the return value is red from EAX, it's that simple. The compilers may add boilerplate code around the main, in fact main() is rarely the real main() function, but that doesn't change the spec.
      - TazeTSchnitzel 9y ago
        Did you read the comment you just replied to?!
        pjc50 9y ago
        The two comments are not incompatible, they are just very different worldviews. One tells you what the standard says (that the termination status is unspecified if main does not return an int), the other tells you what usually happens (you get what happened to be in AX). And as I've just tested, gcc doesn't return zero termination status if you reach the } at the end of main.
        TazeTSchnitzel 9y ago
        Depends if it's in C99 mode. GCC defaults to “GNU89” I think.
        user5994461 9y ago
        Calling conventions are as much a standard as the C spec. The main() is called like a regular function, by the system thing that executes programs. Depending on the compiler and the flags, the main() is not the real entry point of the program. It can add another entry point to do some magic, like setting the return code.
- protomyth 9y ago
  Turbo C back in the day didn’t even give a warning.
- deleted 9y ago
  [deleted]

TazeTSchnitzel 9y ago

It's weird how compilers complain if main() is void, despite it not having to return anything if it's int.

user5994461 9y ago
You have to return something. If you don't, the exit code is the value that happened to be in memory at this point.
- TazeTSchnitzel 9y ago
  Normally, yes. But main() is special and implicitly returns 0, for whatever reason.
  - user5994461 9y ago
    Absolutely not. You can look at a crashing programs and see the return code is a random value. You can also make a program that doesn't return anything and see that it's also a random value, though some compilers on some platforms might initialize that to zero.
    - TazeTSchnitzel 9y ago
      No, it's literally special-cased in the C standard.
      - pjc50 9y ago
        Someone should tell the gcc maintainers then. int main() { int a = 12; } $ gcc maintest.c $ ./a.out $ echo $? 148
        TazeTSchnitzel 9y ago
        $ cat test.c int main(void) {int a = 12;} $ gcc-6 test.c -o test --std=c89; ./test; echo $? 162 $ gcc-6 test.c -o test --std=c99; ./test; echo $? 0 Must be a C99 thing.
        albinofrenchy 9y ago
        This isn't that conclusive of a test -- uninitialized memory is 0 relatively often.
        clarry 9y ago
        https://github.com/gcc-mirror/gcc/blob/4bec7283cda24b180ea7a01ae62214058a8e0020/gcc/c/c-decl.c#L9275 https://github.com/gcc-mirror/gcc/blob/4bec7283cda24b180ea7a...
        pjscott 9y ago
        Okay, that is conclusive. (And I'm pleasantly surprised by how readable GCC's source code is.)
        kaushiks 9y ago
        This has nothing to do with memory. The x86_64 ABI returns values from functions in the RAX register.
        albinofrenchy 9y ago
        Sure; same point applies though -- just because 0 happens to be in RAX doesn't mean it's defined behavior.
- clarry 9y ago
  N1256 5.1.2.2.3 p1: If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
  - user5994461 9y ago
    main() is __cdecl__ or __stdcall__ on the major platforms. That calling convention on x86 specifies that the return value is red from the EAX register. So, when your main() function exits, the return value is red from EAX, it's that simple. The compilers may add boilerplate code around the main, in fact main() is rarely the real main() function, but that doesn't change the spec.
    - TazeTSchnitzel 9y ago
      Did you read the comment you just replied to?!
      - pjc50 9y ago
        The two comments are not incompatible, they are just very different worldviews. One tells you what the standard says (that the termination status is unspecified if main does not return an int), the other tells you what usually happens (you get what happened to be in AX). And as I've just tested, gcc doesn't return zero termination status if you reach the } at the end of main.
        TazeTSchnitzel 9y ago
        Depends if it's in C99 mode. GCC defaults to “GNU89” I think.
        user5994461 9y ago
        Calling conventions are as much a standard as the C spec. The main() is called like a regular function, by the system thing that executes programs. Depending on the compiler and the flags, the main() is not the real entry point of the program. It can add another entry point to do some magic, like setting the return code.
protomyth 9y ago
Turbo C back in the day didn’t even give a warning.
deleted 9y ago
[deleted]