Thread: Pointless Warning?

Other than the excuse of it being too much work for the compiler to check (which I think it a pretty lousy excuse)

With "too much" I mean "too much to be done before the sun explodes", not "too much for those lazy compiler writers to implement". Proving anything non-trivial about an imperative program is nigh impossible.

That's a problem for the optimizer to worry about.

It's a matter of compile time. You'd have to take a huge hit - and I mean HUGE - in compile time so the compiler can derive it's proof.
Did I mention that the hit is HUGE? In a large program, I'm talking about going from minutes to days of compile time, and memory requirements that would make a modern hard drive shiver.

Of course, if any of the relevant code is dynamically linked, you're out of luck anyway, because you can't prove anything about code that's not there.

The optimizers are smart, especially the dead code eliminators, but they're not omniscient. It's unreasonable to put such requirements in the standard.

I'm just saying it should check in the current function to make sure that if the function is supposed to return a value, that it has a return statement either at the end of the function, or at the end of each code branch (such as if, else if, else...)

So, you are saying that even though the programmer can prove that control will never reach the end of the function body, the programmer must put in a dummy return value there anyway? For example, consider a loop that returns from within the loop body but is otherwise an infinite loop.

Sure, why not? All you need to do is put a return statement at the end of the function, and it should handle all situations. Although in some cases a throw might be more appropriate. If you don't think it should ever reach that line, you can put a comment there (and maybe an assert) so others know why it's there.

I find the practice dubious: the return statement would be unreachable code and would obscure the proof that the line is logically unreachable. If we take Sutter and Alexandrescu's recommendation to prefer assertions to exceptions for programming errors, throwing an exception would not be ideal either since control reaching that line indicates a programming error.

Consequently, I think that an assertion would be better than both returning a dummy value and throwing an exception, though the compiler should then not warn that the assertion is unreachable, if it is able to determine as such (that should be the case anyway since the assertion would be ignored in a release build with optimisations turned on).