4 ms·

Quick Summary: The C compiler optimizer replaces printf("Hello World!\n") with puts("Hello World!\n") and the implicit return from main() changes from 13 (the

Quick Summary: The C compiler optimizer replaces printf("Hello World!\n") with puts("Hello World!\n") and the implicit return from main() changes from 13 (the return value of printf) to 10 (the return value of puts)

moffkalast 5y ago
Calls on puts you say?
- mypalmike 5y ago
  The behavior is optional.
- QuestingElf 5y ago
  C is Citigroup
  - littlestymaar 5y ago
    No, C stands for Capitalism.
- helmholtz 5y ago
  Brilliant.
- enlyth 5y ago
  In other words long volatility
deleted 5y ago
[deleted]
Pxtl 5y ago
This sounds like a compiler optimizing bug, in that if the expected behavior of main without a return is that it will return the result of the last function call, then the last function in the main does use its return value and that should not be optimized.
- Computeiful 5y ago
  Yeah honestly this blog post just seems to be highlighting a bug in gcc when it is compiling to an older version of C. Not sure why the author chose to frame it as some big point about the printf function.
  - ncmncm 5y ago
    When I do it on Linux, with gcc 10.2.1, it always returns 0, regardless of "-ansi", "-O2", or what-have-you. So, the author's experience is either peculiar to some old version of cc he used, or to a quirk of BSD. The ISO C++ Standard dictates that if main fails to return a result, the program result is zero. And, g++ does this. [Edit: I'm wrong... with "gcc -ansi -std=c90", with or without optimization, I get the 13! But not 10.]
  - roywiggins 5y ago
    I think that's because the only way to see puts() return value after calling printf is in this weird situation. If you actually assign the return value somewhere and read it, the compiler can't replace it with puts and you'll get the return value you expect. But in this case the compiler is tricked into exposing that it's really calling puts().
  - varajelle 5y ago
    Not a bug in GCC. The program GCC tries to compile is invalid, and the C standard says GCC can do anything it please in that case. So GCC is fine, just fix your program.
- NobodyNada 5y ago
  As far as I understand, there is no “expected behavior of main without a return” under ANSI; it’s undefined behavior as (according to this version of the C standard) a function with an int return type must return an int. The fact that it happens to return the result of last function call is more-or-less a coincidence because the compiler doesn’t bother to clear out or reuse the return value register. If this seems unintuitive, consider a more general example: int foo(int x) { if (x >= 0) return 123; if (x < 0) return 456; } What’s the “expected” return value if neither of the if-statements match? That seems like a nonsensical question because the conditions are clearly mutually exclusive, but if you’re a dumb enough compiler (or the conditions are more complex) you might not be able to prove that. So should it return zero? Should the compiler insert code to save and remember the result of the last function call? According to the C standard, the compiler doesn’t have to handle this situation; it is free to assume that the branches are indeed mutually exclusive, and it will most likely do whatever produces the easiest/fastest code in that case. In the OP’s example, it seemingly just decides to return void (leaving whatever garbage was previously in the return value register for the caller to discover). But it could also have assumed that main must infinitely loop (since there’s no return statement), and omitted the return instruction altogether causing execution to “fall off” the end of the function into whatever happened to be next in memory.

moffkalast 5y ago

Calls on puts you say?

mypalmike 5y ago
The behavior is optional.
QuestingElf 5y ago
C is Citigroup
- littlestymaar 5y ago
  No, C stands for Capitalism.
helmholtz 5y ago
Brilliant.
enlyth 5y ago
In other words long volatility

deleted 5y ago

[deleted]

Pxtl 5y ago

This sounds like a compiler optimizing bug, in that if the expected behavior of main without a return is that it will return the result of the last function call, then the last function in the main does use its return value and that should not be optimized.

Computeiful 5y ago
Yeah honestly this blog post just seems to be highlighting a bug in gcc when it is compiling to an older version of C. Not sure why the author chose to frame it as some big point about the printf function.
- ncmncm 5y ago
  When I do it on Linux, with gcc 10.2.1, it always returns 0, regardless of "-ansi", "-O2", or what-have-you. So, the author's experience is either peculiar to some old version of cc he used, or to a quirk of BSD. The ISO C++ Standard dictates that if main fails to return a result, the program result is zero. And, g++ does this. [Edit: I'm wrong... with "gcc -ansi -std=c90", with or without optimization, I get the 13! But not 10.]
- roywiggins 5y ago
  I think that's because the only way to see puts() return value after calling printf is in this weird situation. If you actually assign the return value somewhere and read it, the compiler can't replace it with puts and you'll get the return value you expect. But in this case the compiler is tricked into exposing that it's really calling puts().
- varajelle 5y ago
  Not a bug in GCC. The program GCC tries to compile is invalid, and the C standard says GCC can do anything it please in that case. So GCC is fine, just fix your program.
NobodyNada 5y ago
As far as I understand, there is no “expected behavior of main without a return” under ANSI; it’s undefined behavior as (according to this version of the C standard) a function with an int return type must return an int. The fact that it happens to return the result of last function call is more-or-less a coincidence because the compiler doesn’t bother to clear out or reuse the return value register. If this seems unintuitive, consider a more general example: int foo(int x) { if (x >= 0) return 123; if (x < 0) return 456; } What’s the “expected” return value if neither of the if-statements match? That seems like a nonsensical question because the conditions are clearly mutually exclusive, but if you’re a dumb enough compiler (or the conditions are more complex) you might not be able to prove that. So should it return zero? Should the compiler insert code to save and remember the result of the last function call? According to the C standard, the compiler doesn’t have to handle this situation; it is free to assume that the branches are indeed mutually exclusive, and it will most likely do whatever produces the easiest/fastest code in that case. In the OP’s example, it seemingly just decides to return void (leaving whatever garbage was previously in the return value register for the caller to discover). But it could also have assumed that main must infinitely loop (since there’s no return statement), and omitted the return instruction altogether causing execution to “fall off” the end of the function into whatever happened to be next in memory.