C and C++ functions without a return statement

Question

While looking through code at work I found some (seemingly) offensive code in which a function had a return type, but no return. I knew the code worked, but assumed it was just a bug in the compiler.

I wrote the following test and ran it using my compiler (gcc (Homebrew gcc 5.2.0) 5.2.0)

#include <stdio.h>

int f(int a, int b) {
  int c = a + b;
}

int main() {
   int x = 5, y = 6;

   printf("f(%d,%d) is %d\n", x, y, f(x,y)); // f(5,6) is 11

   return 0;
}

Analogous to the code I found at work, this defaults to returning the result of the last expression executed in the function.

I found this question, but was not satisfied with the answer. I know that with -Wall -Werror this behavior can be avoided, but why is it an option? Why is this still allowed?

Answer 1

"Why is this still allowed?" It is not, but in general, the compiler cannot prove you are doing it. Consider this (of course extremely simplified) example:

// Input is always true because logic reason
int fun (bool b) {
    if (b) {
        return 7;
    }
}

Or even this one:

int fun (bool b) {
    if (b) {
        return 7;
    }
    // Defined in a different translation unit, will always call exit()
    foo();
    // Now we can never get here, but the compiler cannot know
}

Now the first example could flow off the end, but it never will as long as the function is used "properly"; and the second one could not, but the compiler cannot know this. So the compiler would break "working" and legal, although probably stupid, code by making this an error.

Now the example you posted is a little different: Here, all paths flow off the end, so the compiler could reject or just ignore this function. It would however break real world code that relies on the compiler specific behavior as in your production code, and people do not like that, even if they are wrong.

But in the end, flowing off the end of a non-void function still is undefined behavior. It might work on certain compilers, but it is not and never was guaranteed to.

Answer 2

It's not a bug in the compiler but the code is obviously badly formed. on x86 architecture, (R|E)AX is used as the accumulator register and also for return values.

So let's take a look at a completely unoptimised disassembly: https://goo.gl/TihXpa

• You'll see that the code for f() is indeed using eax to store the addition result.

• However... go ahead and use -O1 (or any optimisation level that's more aggressive) as a compiler option (top-right box) and see what happens now.

...We find that the compiler has correctly realised that the function doesn't explictly return its result and it just becomes a no-op.

Hence, this nasty piece of code is a perfect example of something that can work as-intended as a debug build but fail horribly when any optimisation is applied.

Answer 3

The result of a function with a return type but no return statement is undefined (except in C++ with main, where the return value is 0). It's also not a syntax error, since the grammar uses a general form for a function that work for both value-returining and void functions.

Odds are what's going on here is that the result of the last expression is getting stored in the same register (on an x86, EAX or RAX) that the compiler is using for the return value of the function. When the function returns, the return instruction leaves this register alone, and the calling code simply assumes the value there is the return value of the function.

Answer 4

In practice, the value being returned is probably the last value in some machine register (e.g. the one used to compute c). However, according to the standards, both the return value and results if the caller accesses/users the returned value are undefined.

As to why this sort of abusive/ugly code construct is allowed.... Firstly, in early versions of C there was no void keyword, and - if no return type was specified - return type for a function was int. For functions that were actually intended to return nothing, the technique was to (implicitly or explicitly) define them as returning int, not return any value, and have the caller make no attempt to access/use the return value.

Since compiler vendors had some freedom in how they handled this sort of thing, they didn't have to take any particular care in ensuring there was a valid return value, or ensuring that the return value was unused. In practice, it was largely fortuitous that - if the return value was accessed - it often happened to contain the value of the last operation in the function. Some programmers stumbled upon this behaviour of their code and - since code that was terse and cryptic was often viewed as some virtue at the time - made use of it.

Later on, even when the compile vendors in question tried to change the behaviour (e.g. to emit an error message and reject the code when a function "fell off the end"), they received bug reports from developers (some of whom were quite vocal) about their programs no longer working. Sad as it is, the compiler vendors caved to the pressure. Other compile vendors also caved to similar bug reports (of the form "gcc and compiler X does it this way - yours should too") because a number of those bug reports came from developers at large companies or government bodies who were paying customers for the compiler vendors. This is the reason that such things are diagnosed by most modern compilers (usually as an optional warning, disabled by default, such as gcc's -Wall option) and give behaviour that the developers expected.

The history of C, and therefore C++, is littered with a number of obscure features like this, which result from programmers exploiting some obscure behaviour of their early compilers and lobbying to prevent the behaviour being disabled.

The best modern practice is to turn on compiler warnings, and not to exploit such features. However, there is still enough legacy code - and developers who don't want to update codebases for various reasons (e.g. having to provide a slew of documentation to convince regulators the code still works) to stop using such features - that the features remain supported by compilers.

Answer 5

At computer architecture level: if there is a default place in memory where results are stored after simple calculations, this memory could be returned (by accident) with the correct answer.

Here it is:

For x86 at least, the return value of this function should be in eax register. Anything that was there will be considered to be the return value by the caller.
Because eax is used as return register, it is often used as "scratch" register by calee, because it does not need to be preserved. This means that it's very possible that it will be used as any of local variables. Because both of them are equal at the end, it's more probable that the correct value will be left in eax.

Check here a similar topic.