In practice, I would also have used goto, if I was writing a series of conditionals where I only have a single error block. The code could be restructured to link all of the conditionals into a single clause, yet it also tries to retain the specific error code for the check that failed. I would really dislike to see the following:
if ((e = foo) != 0 && (e = bar) != 0 && ...) goto fail;So what then? Do we call upon the software engineering folk to better analyze programs and find these mistakes? Or write style guidelines that require braces for every if, and ban every goto? And then the employee's manager is required to sign off on every exception. These are some of the many proposals floated for addressing this, and often made by programmers touting the superiority of their proposal and how this would never happen to them.
Leave me to shrug. I'll use my goto, sparingly. And I'll continue to try to impress on students that they and all of us programmers will make mistakes so write elegant code to help find these bugs. Until then, if anyone has a good construction for the error code that doesn't require goto, let me know.
5 comments:
Adam Langley has a great summary of the problem (and why it probably went unnoticed):
https://www.imperialviolet.org/2014/02/22/applebug.html
I'm reminded of the saying that ignoring compiler warnings is like disabling the check engine light in your car.
One could also note that while Apple is now using Clang / LLVM rather than gcc, clang tries to be compatible with gcc's way of doing things. This had the result here of not including unreachable code warnings, even with -Wall. Although, there are separate discussions as to whether the compiler should warn about unreachable code; as for instance, programmers (including myself) will disable a block of code with a return statement, etc and this would give warnings.
I've done that too (use a return statement to temporarily alter code flow when debugging.) Do it often enough and eventually you'll accidentally leave a debugging return somewhere unintentionally.
I usually set a boolean flag: "if (DEBUGGING) {return;}" No compiler warnings, and no change to flow when DEBUGGING = false if I forget to remove every last testing block. Better: remove the flag declaration and your code won't compile if you've left a testing block somewhere.
I stand by my check engine light analogy. ;)
GnuTLS also had a vulnerability this week found near a goto, and the internet once again cried foul - proximity also apparently now implies causality. Threatpost did a write up about how the two were different and how in both cases goto wasn't the problem.
(Since I cannot edit my previous comment) At least, goto is not inherently the problem!
Post a Comment