Archive for February, 2014

Preventing a goto fail (part 2)

I’ve been interviewing candidates lately, which has made me think about everyday things in terms of screening/interviewing questions. Perhaps then a good question for an iOS developer is “How would you prevent a goto-fail situation?”.

Of course, “braces” comes up first, and compiler options may come up second, so let’s change that to “Aside from braces and compiler settings, how would you prevent a goto-fail situation?”.

Over the last few days, I’ve been reversing my role to think how I would answer that from an interviewer.  The idea that occurs to me the most boils down to “defensive coding” or “best practices and standards”. Now that’s way too vague.  As an interviewer I would ask for details.  I’m sure any practiced interviewer would.

For me, the biggest problem with the goto-fail code is the assumption of success until failure throughout the instructions. In critical code, it is better to assume failure until success is specifically reached.  Read the rest of this entry »

Preventing a goto fail

There was an embarrassing coding moment in developer news recently.  When I think about how easy it is to make similar mistakes, I starting thinking like Steve Maguire in his book “Writing Solid Code”.  How could this problem have been detected or prevented? (And I’m not debating the use of GOTO’s. Someone else can do that.)

I first heard Steve Gibson describe the code on “Security Now!” podcast episode #444 (show notes). How would the compiler detect that? After I got back to a computer where I could look at it, I saw the writeup at Adam Langley’s ImperialViolet blog. Adam discussed things like how the consistent use of braces might have made it more obvious.  But Solid Coding principles stress automatic ways to detect problems, so I was happy to see Adam’s note about the -Wunreachable-code option of the Clang compiler. That might have detected code being disabled by the GOTO, but as Adam also pointed out, it is not one of the options included in -Wall option.

Adam didn’t go into what the option would reveal, so I created a quick command-line tool from templates in Xcode. Compiling with the default options failed to note the problem. Adding -Wall did not detect the problem.

But when I added -Wunreachable-code to the “Other Warning Flags”

Xcode-both-warnings-smaller

Xcode finally found the problem.  (Note that I had “Treat Warnings As Errors” set to YES.)

DeadCodeWarning4-crop-small2

 

So, adding the -Wunreachable-code compiler warning is the lesson of the day.   I’ll be looking into it for my project tomorrow.

 

 

 

Tags: , , ,