[Cryptography] The GOTO Squirrel! [was GOTO Considered Harmful]

[Christian Huitema]

> This could be, and should have been, caught with automated testing.  

Of course it should have been caught. And of course you should check test
coverage, which should be near 100% for a critical procedure like that, But
this is also a story of multiple layers of protection failing one after the
other -- code style, code review, automated compiler checks, unit tests, end
to end tests... 

And the "goto considered harmful" should indeed be included in the coding
style. Like many others I could not help but write a small blog about it --
http://huitema.wordpress.com/2014/02/24/the-apple-tls-bug-and-coding-guideli
nes/. 

The "goto fail" programming style has many supporters, often using some
"CHECK_AND_FAIL()" macro. It does not generate extra instructions, it allows
for easy step by step debugging, and it does not require cascades of
indentations. But many of the issues that Dijkstra pointed out are still
there. In particular, it is very easy to get a memory leak or some other
side effect due to partial execution, much easier than if you enforce the
strict "structured programming" requirements.

Of course, not using goto does not guarantee no bug. In fact, the second
iteration of Patrick Chkoreff's "no goto" refactoring still has a bug -- it
will only output an error message if all test except the last one succeed,
instead of "if any test fails." 

-- Christian Huitema