goto didn't fail;

it actually worked pretty well, and this is just my quick take on the infamous goto fail; security issue Apple had recently, an issue perfectly explained in this Adam Langley Weblog post.

what is wrong, in a sentence

Citing Adam Langley, here in my opinion exactly what is wrong in the modern software industry:

If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code. That's surprising to me ...

Do you see that? Adam trusted the compiler to solve logic problems for him, without even mentioning for a second that a basic test would have shown the problem against an expected output apparently impossible to reach/obtain.
Bear in mind this post is not about Adam and the fact I am surprised too his example didn't warn, but that sentence represents way properly the common thinking in the actual industry, IMO (so please Adam don't take it personally, thanks).

syntax has nothing to do with security

every programming language has its own syntax gotchas, but this does not mean that every program is written badly or it can fail. The amount of criticism behind brackets, indentation, parenthesis, or the goto statement, even from the wired post, is embarhassing:

Using “goto” statements in any form has long been considered a poor programming practice, though everyone does it anyway.

It's way too easy to blame a statement and make this story a light emphasis on how bad is goto and everyone using it should burn in hell ... I wouldn't even be surprised if Apple will remove such statement from everywhere in XCode so that can go along with what really went wrong in this story ...
Truth is, an accidental early function return would have caused exactly same problem, stop blaming goto then!

missing tests and 100% code coverage

everyone knows testing might be hard and time consuming, but it does not matter how respected is your OS timeline if all your software does is to easily expose stuff due lack of time to test the most basic part of the security data exchange ... do you know what I mean?

a gently myth buster on SW development

just to remember what is not SW development about ... shall we?

1. compilers and compiled languages do not automatically make your software secure; you can type by accident the function/method detractMoney(amount) twice and let the user with 200% less money ... now tell her it was her paying twice by accident ...
2. linter do not make your code safer neither; indeed linters are more about code readability and practices, these have nothing to do with security and specially in JS world you must be a fool to think that varname === undefined will solve anything in your code
3. tests are not an option, and for gosh sake this must be 120% true when "enterprise" or security related code is in place. It does not matter how cool is your programming language or the tool you are using to build your software, until you have a very high/good code coverage via any sort of test you can think of, you might be, at that point, good to go but it won't be never late to add a test or be sure that something else, just a change, didn't cause a regression

Before I've met great developers that couldn't stress more about testing everything, I've worked for companies that didn't care about tests, used the classic excuse "we have no time for that" or believed that the programming language, since compiled, was better than JavaScript and error/disaster prone by default because of types or some magic death code elimination.

This is bullshit, and I don't expect such kind of bullshit from #1 corporates that will silently pass behind the scene covered by simplification of a problem that has never been caused by missing brackets, parenthesis, or a goto statement.

Get real and solve your real problems, 'cause your scanned finger prints smells already rotten knowing that SSL abc wasn't triply reviewed, and passed to production miserably without a good code coverage for it.

Thanks for listening!

---

P.S. this case was just too fuzzed to not be used as example where tests outperform compilers and linters but this post has really nothing strictly to do with Apple itself! Any company/corporate lacking tests (unit, integration, smoke, etc) could easily fail in security, as well as everything else, problems