The "goto considered harmful" article by Dijkstra is more nuanced (and that wasn't even its intended title) and doesn't really address the way the goto you are seeing are used.
They are a very common pattern in C, for error checking and cleanup in case of error. It's much more readable than to nest conditional statements.
if (some_parameter > max_valid_value)
goto error;
if (some_function() <= )
goto error;
...
...
if (some_alloc() == NULL)
goto error;
...
...
...
...
error:
// cleanup what needs to be freed,...
It can also be quite useful to exit nested loops for example. It's commonly used in low-level C.However, when you start goto'ing backwards instead of always forwards, it becomes terrible for readability, so it is avoided (well, most of the time).
For more reading on the subject, this excerpt from Code Complete by Steve McConnell discusses the subject further : http://www.stevemcconnell.com/ccgoto.htm
e.g. https://stackoverflow.com/questions/788903/valid-use-of-goto...
In response to Dijkstra's letter, Knuth wrote the article 'Structured Programming with go to Statements' (http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoT...). He defends certain uses of goto, such as error exits.
Both cannot be wrong can they? It is a logical impossibility.
And in other words, nobody should be writing anything in C. Ever. The need to be compatible with programs written in C violates my rule against writing anything in C and is therefore not a valid reason to write crypto stacks in C.
I don't think it's the best fit, but it's a lot better than many current solutions. I personally prefer Haskell for anything others would write in Go, however many may find Ocaml or Erlang to fit them better.
However I'm biased and believe that functional programming is a better fit, more bug-free, easier, and simpler for most use cases than imperative programming.
Compare http://golang.org/src/pkg/crypto/x509/x509.go to https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150cc...
Other imports/files can be seen at: http://hackage.haskell.org/package/x509-1.4.10/docs/src
And in other words, nobody should be listening to thrownaway2424. Ever.
In Apple's case "goto" made it possible for the bug to occur, but there's no reason a different statement (or other typo) could cause equivalent damage.
I think a common thread with both of these bugs is testing the failure cases, but to be fair to both validating software by finding bugs and/or validating functionality is affirming the consequent and you eventually need to ship.
Bad software engineering. Their internal routines return negative value to indicate failure, but to the caller they translate it to true/false.
Or do you just mean that its abused a lot? (in which case, I'm less interested.. :) )