Getting “control reaches end of non-void function” warning even when I've covered all cases

问题

Why if I have two conditions while both returns the right type in a function as it should be, I am getting an alarm.

control reaches end of non-void function [-Wreturn-type]

bool EtherTrafGen::isGenerator()
{
    if (multipacket) return par("destAddresses").stringValue()[0];
    else if (!multipacket) return par("destAddress").stringValue()[0];
}

What is the way to correct such an alarm?

回答1:

Even though control can never reach

bool EtherTrafGen::isGenerator()
{
    if (multipacket) return par("destAddresses").stringValue()[0];
    else if (!multipacket) return par("destAddress").stringValue()[0];
    //here
}

The compiler can't know that (since it's an else if) and it warns you about potential undefined behaviour if it is reached (maybe another thread modifies multipacket after the first check etc). You can just add a default return value to satisfy the compiler:

bool EtherTrafGen::isGenerator()
{
    if (multipacket) return par("destAddresses").stringValue()[0];
    else if (!multipacket) return par("destAddress").stringValue()[0];
    return false;
}

Or just cut the whole else if since it's either true or false:

bool EtherTrafGen::isGenerator()
{
    if (multipacket) return par("destAddresses").stringValue()[0];
    return par("destAddress").stringValue()[0]; // multipacket must be false here anyway
}

回答2:

You are missing one case:

bool EtherTrafGen::isGenerator()
{
    if (multipacket) return par("destAddresses").stringValue()[0];
    else {
        if (!multipacket) return par("destAddress").stringValue()[0];
        else ???? <---- what should be done here
    }
}

回答3:

I'll start by saying that the way you've structured your condition is quite exotic. You should just write it as:

if (multipacket) doX()
else doY()

It is true that the compiler should be smart enough to figure this case out, and not print an error.

However, your compiler isn't that smart. It's better not to have the warning, than to have it and know you're right.

Looking more broadly, there is a possibility that the code above is wrong, and it's not just the case that the compiler is not powerful enough in its analysis.

If the following code occurs in a multithreaded context, you might have rare threading issues where on the first access to multipacket you read a false, thus forcing you go to the second branch, and on the second access you read a true, thus forcing you go go out of the function without any return value. This case might happen if another thread modifies multipacket in between the two times it is read.

Granted, it's a small chance, as even if multipacket is changed by a separate thread, the modification might not be visible in that method immediately, because the value is in a register/cache/other temporary location that has been introduced by the compiler.

But why take the chance and write un-idiomatic code and have a warning on your hands?

来源：https://stackoverflow.com/questions/41892864/getting-control-reaches-end-of-non-void-function-warning-even-when-ive-covere

标签

c++

multithreading