Bug 12342 – Deprecate not reachable code?

int foo() { int x = 0; goto exit; if (true) x++; x = 20; exit: return x; } void main() {} dmd 2.066alpha gives: test2.d(4,5): Warning: statement is not reachable test2.d(6,5): Warning: statement is not reachable Perhaps it's a good idea to turn such warnings into deprecation messages. This deprecation avoids cases like a famous bug: http://en.wikipedia.org/wiki/Backdoor_%28computing%29 >In late February 2014, Apple elliptically notified users of their OS of the "goto fail" backdoor that was caused by an error. This error voids the SSL authentication process, and exposes the user to a Man-in-the-middle attack.[12][13][14] The "goto fail" bug is nicely diff-listed by Arthur in the Guardian expose.[14]< http://www.theguardian.com/technology/2014/feb/25/apples-ssl-iphone-vulnerability-how-did-it-happen-and-what-next

The number of false positives puts this firmly in the warning/lint territory IMO. Unreachable code is highly common for me when writing and debugging.

> The number of false positives puts this firmly in the warning/lint territory IMO. Unreachable code is highly common for me when writing and debugging. Agreed.

Personally I find it extremely annoying when I get "unreachable" errors for assert(0);. Sometimes I want to add it just to figure out whether execution has reached some part of my code, e.g.: ----- void function() fp1; void function() fp2; void main() { fp1(); assert(0); // triggers warning fp2(); } ----- Without the assert(0) I can't tell from the stack-trace at what point something went wrong: ------ object.Error: Access Violation ------ With the assert injected, if it is reached I'll get back: core.exception.AssertError@test(8): Assertion failure Which at least tells me the code before line 8 works ok.

(In reply to comment #3) > Personally I find it extremely annoying when I get "unreachable" errors for > assert(0);. Sometimes I want to add it just to figure out whether execution has > reached some part of my code, e.g.: I think you are using assert(0) for the wrong purposes, assert(0) is a code flow tool, like break and continue, e and it's used to tell the compiler a certain code branch can't be reached. Perhaps you have to throw a Error instead. Given the lack of love you show for this idea, I close down this ER as Invalid.

(In reply to comment #4) > I think you are using assert(0) for the wrong purposes, assert(0) is a code > flow tool, like break and continue, e and it's used to tell the compiler a > certain code branch can't be reached. Perhaps you have to throw a Error > instead. It's just a temporary use to find problems. Anywho the real problem is the complete lack of stacktraces when a null function pointer is called. I'm not sure whether this is filed.

(In reply to comment #5) > the real problem is the > complete lack of stacktraces when a null function pointer is called. I'm not > sure whether this is filed. Null pointers in D are not protected by an assert. This is a design decision of Walter that lot of people (me included) doesn't like.