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.

> As far as I understand, there is no “expected behavior of main without a return” under ANSI; it’s undefined behavior

You are right. There are still a lot of so-called developers who cannot understand the concept of _undefined_ behavior.

No, it's not undefined behavior. Only the status returned to the host environment is undefined. (And in C99 and later, the status is 0.)

As for your example:

int foo(int x) { if (x >= 0) return 123; if (x < 0) return 456; }

that has undefined behavior only if the caller uses the value. (That's to cater to ancient C code written before the void type was introduced.)

Any such expectation is unfounded. The C90 standard says:

"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. If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined."

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.

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.

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().

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.]

> the expected behavior

Which part of "undefined behavior" is not clear to you?