Posts Tagged Solid-Coding

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 finally found the problem.  (Note that I had “Treat Warnings As Errors” set to YES.)



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




Tags: , , ,

Solid Code: Mixing Objective-C and C++

If you’ve noticed that there’s been a long time between this post and the previous one,  you are right. My day job has been keeping me busy.  But that’s why I can get on with the topic: mixing legacy C++ with Objective-C.

After trying things a few ways,  I’m finding that one basic assumption difference between the languages can trip you up: the assumption about calling a method or function with an object pointer to zero (a.k.a. nil or null or NULL).

Since the C++ will generally be legacy code,  its natural for Objective-C objects to wind up containing pointers to C++ objects.  After that, its pretty easy to wind up calling C++ functions almost directly from accessors like:

This is functional,  but from a solid-coding standpoint,  it is too bug-prone and too hard to debug.  If the above statement crashes, which part of it failed?

Objective-C assumes that calling member methods with nil object pointers is OK.    (i.e., a nil ‘self’ pointer is not an error.)  Any such attempt just automatically returns zero.

C++ however, assumes that member functions will never be called against a NULL pointer.  (i.e., a NULL ‘this’ pointer.)  Any such attempt will probably crash an iPhone with EXC_BAD_ACCESS.

My point here is you should put the pointer into a variable, then call the function from that variable:

Now the language assumptions are clearly separated.  Nil pointers in the first line can be safely assumed to have zero method results. And the C++ in the second line can be more easily debugged if it fails.  (And we can easily check our C++ pointer for NULL before calling its function.)

The crash from the C++ code will most likely happen when the member function tries to dereference a member variable.  An instance’s member variable is held at an offset from the pointer, so if the pointer is zero, the member equates to an address that is near zero.  Addresses near zero are invalid on the iOS.

So there you go,  if you have to mix Objective-C and C++,  avoid mixing them on the same line.

Tags: , , , ,