If you missed it the 35th and 36th occurance of goto fail that really does go directly to fail.

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;

Compulsory bracing of blocks following if/while etc is a piece of syntax Perl got 100% right. Python also got it right in a different way with whitespace.

C and C++ really don't have an excuse for not MANDATING compiler warnings at a minimum. The use of lack of bracing is "I'm too lazy and much too cool to type 2 characters." This is major fuckup number 4,294,967,294 So that muppets who keep claiming "We need backwards compatibility with brittle and broken code." Should probably spend about a decade in the room full of mirrors HAVING A GOOD LONG, HARD LOOK AT THEMSELVES. (Caps used advisedly, in this case, we need to do a bit of yelling at these standards committee weenies refusing to, you know, fix the damn bugs in the standard).

Edit to point out this how how the NSA MITM'd you when you were using OSX, in case you missed what the file is too.

> If you missed it the 35th and 36th occurance of goto fail that really does go directly to fail.

Yes, I and many others seem to have missed it. That is a legitimate bug.

I think the post title should highlight this issue. Now it seems like it's just a "goto is bad but apple uses it anyway" post without much point.

It's kind of a pun (probably unintentional) in that there is a particular erroneous goto statement, i.e. a "goto fail".

> If you missed it the 35th and 36th occurance of goto fail that really does go directly to fail

Whoa, that was entirely unclear from the submission that this was the point. But then, I guess I still don't see what is the point. Why post this here and not file a bug or something?

Not obvious is it. It's only ssl so it's not like it's important. The non-obviousness of it and the spectacularness of the goto fail is, well, in my view, the whole point. C should not still suck this bad. One line un-braced blocks are a standard bug. Why no fixy? Why? What do we have to do?

It's likely the cause for this issue:

http://support.apple.com/kb/HT6147

Reported Nov 28th (!):

http://i.imgur.com/CoALymQ.png

https://gist.github.com/rmoriz/fb2b0a6a0ce10550ab73

Good catch ! Thanks for pointing that out.

What's the point of this post? If you're unfamiliar with "goto fail" in C code... it's a very common error handling pattern.

I'm working on some ffmpeg code at the moment. ffmpeg 2.0 contains 554 occurrences of "goto fail".

Edit: okay, it appears that the point of OP's post is that someone appears to have copy/pasted an extra "goto fail" at line 631, short circuiting the remainder of the SSLVerifySignedServerKeyExchange function and needlessly jumping to fail. I assume this was the code that Apple needed to patch in iOS 7.0.6 today?

Apparently that was it.

http://www.reuters.com/article/2014/02/22/us-apple-flaw-idUS...

http://www.zdnet.com/major-apple-security-flaw-patch-issued-...

You know, sometimes there is legitimate usage of the goto.

This file is one of them: multiple branches that can end to the same leaf.

Another would be break in interlocked loops, or clean failing when the software detect an hard failure and no memory can be used anymore.

For this last case, you can also prepare some error handling frames at the init, and longjump (like a goto, but with already allocated stack memory) when it's time to fail.

What is the point of this post?

In the C programming language, "goto fail" is a perfectly acceptable means of (function local) error handling because of the absence of any kind of exceptions (setjmp doesn't count). Just look at any significant C program, and you'll see that this is used a lot. The alternative for "goto fail" is duplicating the clean up code for each and every error condition that happens in the function.

Blindly following advice like "goto is bad" and applying it everywhere is a bad idea. You should try to understand the reasoning behind it.

You should not use goto for control flow if possible, but it's not bad practice to use "goto fail" for cleaning up on error conditions.

Two consecutive goto fail statements, but no unreachable code warning in the builds?

I'm convinced the warnings are there, but were ignored.

EDIT: The compiler I use( based on lcc ), gives an Unreachable code warning.

I wonder if the goto confuses the compiler

> https://www.imperialviolet.org/2014/02/22/applebug.html

> 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.

Reminds me of the inverse of the goto error pattern.http://computationallyendowed.com/blog/2012/12/03/ifs-and-an...

patio11 says[1] 'I hereby propose "goto fail;" as a meme for unfortunate security mistakes. (Not singling out Apple -- we all make them.)'

[1] https://twitter.com/patio11/status/437182770754752513

I feel like there should be something obvious here that I'm missing...

Search the file for 'goto fail'

Yes, then?

Upvote!

What does the title mean?

how come all the includes are commented out in this file?

That's a nice bug pattern for Underhanded C...

Goto lives!

Long live the goto. and the Fail.