隐式int返回值C function

Question

I've googled and just can't seem to find the answer to this simple question.

Working on a legacy code base (ported to Linux recently, and slowly updating to a new compiler) and I see a lot of

int myfunction(...)
{
// no return...
}

I know the implicit return TYPE of a function is int, but what is the implicit return VALUE when no return is specified. I've tested and gotten 0, but that's only with gcc. Is this compiler specific or is it standard defined to 0?

EDIT: 12/2017 Adjusted accepted answer based upon it referencing a more recent version of the standard.

Answer 1

From the '89 standard as quoted in the new testament:

Flowing off the end of a function is equivalent to a return with no expression. In either case, the return value is undefined.

That standard usually expresses the on-the-ground behavior of pre-existing implementations.

Answer 2

Such a thing is possible, but only under the assumption that the return value of the function is never used. The C11 standard says in para 6.9.1:

If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.

(AFAIR previous version of the standard had similar wording)

So it would be a good idea to transform all the functions of that sort that you have to void functions, so no user of such a function could be tempted to use the return value.

Answer 3

The return statement is never mandatory at the end of a function, even if the function return type is not void . No diagnostic is required and it is not undefined behavior.

Example (defined behavior):

int foo(void)
{
}

int main()
{
    foo();
}

But reading the return value of foo is undefined behavior:

int bla = foo();  // undefined behavior

From the C Standard:

( C99 , 6.9.1 on p.12) "If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined."

The main function is an exception to this rule as if the } is reached in main it is equivalent as if there was a return 0; statement.

( C99 draft , 5.1.2.2.3 on p.13)...reaching the } that terminates the main function returns a value of 0.

Answer 4

That's simply undefined behaviour; if you don't populate the return area (which for example is generally eax/rax on x86 family processors ), it'll have the value last set up through some side-effect in your function.

See Is a return statement mandatory for C++ functions that do not return void? which is basically a duplicate of this question (except that it's tagged as C++).

Answer 5

If the return statements consistently do not return a value, the function is best converted to, and declared as, returning void :

void myfunction(...)
{
    ...
    return;
    ...
}

If there are some some return expr; and some return; statements in the function, then you need to decide which is the better behaviour, and make them consistent — either always return a value and leave the type as int or never return a value and change the type to void .

Note that you'll need to declare functions modified to return void (in a header, unless they are — or should be — static and hidden in a single source file) since the default return type (assumed return type) of int is no longer valid.

Answer 6

It may always be zero in that function, but on most architectures (certainly x86) the return statement moves the contents of a specific register to a specific place on the stack which the caller will retrieve and use as its return function.

The return statement will place the variable passed to it in that location so that it'll be a different value. My experience with not placing a specific return statement is that its fairly random what gets returned and you can't rely on it being the same thing.

Answer 7

I'm certain that it is undefined behaviour for a function whose return type is not void to omit a return statement. In C99 there is an exception for main , where if the return statement is omitted, it is assumed to return 0 implicitly, but this doesn't apply to any other function.

It may work on a specific platform/compiler combination but you should never rely on such specifics. Using any kind of undefined behaviour in your code makes it unportable. It is common to see undefined behaviour in legacy code though.