Gcc error control reaches end of non void function

1. Use the return Statement at the End of the Function Body
2. Use the return Statements at the End of Each Code Path of the Function Body

This article will explain several methods of solving control reaches end of non-void function error C++.

Use the return Statement at the End of the Function Body

Non-void functions are required to have a return type. Consequently, the function needs to have a statement that returns the object of the corresponding type. If certain compiler flags are passed, this type of error or warning might get suppressed entirely, which will lead to run-time faults if the given function gets called in the program.

The following example code has the reverseString function defined, which takes a reference to a string and returns the string value. If we look into a function body, there is no return statement. Even though the reverseString does not pass any arguments to the caller function, the compiler only displays the warning message, and the executable program is built anyway. If the function is called, then the control flow would most likely lead to a segmentation fault.

#include <iostream>
#include <algorithm>
#include <iterator>

using std::cout; using std::endl;
using std::string; using std::reverse;

string reverseString(string &s){
    string rev(s.rbegin(), s.rend());
}

int main() {
    string str = "This string is arbitrary";
    int cond = -1;

    cout << str << endl;
    cout << reverseString(str, cond) << endl;

    return EXIT_SUCCESS;
}

Use the return Statements at the End of Each Code Path of the Function Body

Another scenario where the control reaches the end of a non-void function is when the conditional blocks don’t have the return statements in every path. Thus, if the execution in the non-void function is branched and if statements don’t cover every possible path, then there needs to be an explicit return call at the end of the function body.

The next example demonstrates the string manipulation function with two conditional paths that pass the return value to the caller function. However, some cases are left not evaluated for the given condition, which implies that control flow might reach the end of the function block and cause run-time errors.

#include <iostream>
#include <algorithm>
#include <iterator>

using std::cout; using std::endl;
using std::string; using std::reverse;

string reverseString(string &s, int condition){
    if (condition == -1) {
        string rev(s.rbegin(), s.rend());
        return s;
    } else if (condition == 0) {
        return s;
    }
}

int main() {
    string str = "This string is arbitrary";
    int cond = -1;

    cout << str << endl;
    cout << reverseString(str, cond) << endl;

    return EXIT_SUCCESS;
}

You will possibly see the warning below.

Main.cpp:15:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
1 warning generated.

This problem comes from a misunderstanding of the flow of control in your algorithm. Here’s a representation of that control flow in pseudocode:

if (outer-condition-1)
    if (inner-condition-1)
        return 1
else if (outer-condition-2)
    if (inner-condition-2)
        return -1
else
    return 0

If you translate this into a flow chart, you will see why the compiler is yelling at you:

An else block is only ever related to one if...elseif...else construct at a time, so the last else block is attached only to the outer if conditions and not to the inner if conditions. If an outer condition evaluates to true and its inner condition evaluates to false, the else block will not be executed at all. This means the function will never encounter an explicit return statement, which is what the compiler doesn’t like; every function must always return something, no matter what input it receives.

There are a few ways to fix this. The most direct solution is to add a return statement at the end of the function, outside of the conditional statements, but that’s a bit sloppy—it can hide problems that would otherwise throw errors, making it a bit harder to find bugs.

Another way is to flatten your nested conditions, so that the pseudocode looks like this:

if (outer-condition-1 and inner-condition-1)
    return 1
else if (outer-condition-2 and inner-condition-2)
    return -1
else
    return 0

That might be appropriate if you’re sure your program is working as intended with the current setup. But if you need something unique to happen when an outer condition is satisfied and an inner condition is not satisfied, you need to keep the nested structure but deal directly with every possible outcome:

if (outer-condition-1)
    if (inner-condition-1)
        return 1
    else
        return 2
else if (outer-condition-2)
    if (inner-condition-2)
        return -1
    else
        return -2
else
    return 0

In either case, once the program reaches the first if statement, every path available to it will result in an explicit return statement, thus avoiding the control my reach end of non-void function message from Clang.

A related concept is «single entry, single exit» (SESE), which would demand that your function return a value only once at the end, rather than using the «early return» statements inside the conditional logic. This usually means defining an extra variable to hold the value that will be returned; for example:

declare int r
if (condition-1)
    r = 1
else if (condition-2)
    r = -1
else
    r = 0
return r

For those interested in a more detailed examination of the SESE concept, you can find a huge amount of discussion online and in programming texts; I like this question on programmers.SE, which contains a variety of stylistic and historical perspectives in its answers.