control may reach end of non-void function... but not really

Question

I have an error message from the compiler that many others have reported, but I know why I got it and how to fix it. I'm posting this question because I think the error message is wrong and I'm hoping for confirmation.

I'm working on pset3, the fifteen game, but I think this question is more of a general question about how the compiler works.

fifteen.c:274:1: error: control may reach end of non-void function [-Werror,-Wreturn-type]

Here's the related block of code:

bool won(void)
{
    // Go through each row and column. The tiles should be in order, so we only
    // need to compare to a simple counter.
    int counter = 0;
    for (int row = 0; row < d; row++)
    {
        for (int column = 0; column < d; column++)
        {
            // If we've reached the last row and column, we don't need to check
            // the value because we've already checked the values of every other
            // row and column.
            if (row == d - 1 && column == d - 1)
            {
                return true;
            }

            // If the tile value in the current row and column doesn't match the
            // pre-incremented counter, we didn't win yet.
            if (board[row][column] != ++counter)
            {
                return false;
            }
        }
    }
    // return true; // This shouldn't be necessary.
}

Just to be clear, I know that if I uncomment that return true; the error goes away. Is there really any way that control can reach the end of this non-void function?

I'm iterating through every element in a two dimensional array and it will either return true because it has reached the end and all the values were in order or it will find a value that isn't in order and return false. It can't get to the end without returning a value, can it?

Is this a case of an overly cautious compiler combined with -Wall -Werror, or am I missing something?

Thank you.

Answer 1

It's not so much that compilers are overly cautious, it's that they're stupid and can't actually think. While it may be logically impossible to get through the function without hitting a return statement, the compiler doesn't see it that way. It is only smart enough to detect that all of the returns are contained in some kind of conditionals - if statements, for loops, etc. - where it is possible that the code may not actually get past the conditionals to the return statement. It doesn't matter that the logic dictates that it must get to one, only that on it's face, it's possible that it won't.

It might be possible for the powers that be to enhance the compiler to be that smart, but then how long would it take to do the checks and compile the program? I'm thinking that it's a matter of making the compiler only sufficiently smart to do the job in the shortest time.

As a side note, there's a problem with your final return true statement. Yes, it's appropriate to put in a 'catchall' return statement, but the problem is the 'true'. If a function is designed to verify that something is actually true, it should ONLY return true when the verification actually succeeds. A catchall return true can result in a false positive. The catchall should be return false.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)