Valgrind

Many of us have wanted Valgrind on OS X for a long time, and now we finally have it, thanks to Greg Parker. Valgrind provides some impressive dynamic analysis that complements the static analysis we can get from clang's checker. This interview with the original author has a good description of what it does and how it works.

I've used Valgrind a bit, and it has earned its place in my toolbox. Here are some things I've learned.

While the LLVM checker analyzes your source files and tries to check every possible code path, Valgrind analyzes your built executable and only checks the code path that you specify. LLVM's checker uses lexical analysis and hypothetical variable values to point out problems. Valgrind, on the other hand, translates your executable's machine code into an instrumented bytecode representation, and runs that code in a virtual machine. There are no hypothetical values, so the accuracy of the results is much higher, but the coverage is drastically reduced.

Valgrind instruments ALL of the code that your executable executes, including libraries/frameworks/bundles that were linked against or dynamically loaded. This is possible because Valgrind's input is the machine code that you execute, not the source code that you compile. This provides tremendous opportunities for us to help improve the quality of the binaries we use, but do not own.

With the previous two paragraphs in mind, it is important to note that the actual code path taken by an executable can differ from launch to launch, even when launched repeatedly with the same arguments. Maybe a system cache gets updated, or one of your linked frameworks decides to contact an update server, etc. When your code exercises different paths, different code paths get checked.

Valgrind has a firm grip on your RAM. If you overflow or underflow a buffer on the heap, you'll hear about it. If you read from or write to freed memory, you'll hear about it. If you allocate with new and deallocate with delete[], you'll hear about it.

Valgrind can catch some errors that clang's checker cannot, and vice versa. And there are other errors that both tools will catch. By using these two tools on all of our projects, we can improve our code as well as other people's code that we use at runtime.

Hat's off to the devs who've worked on Valgrind and LLVM's checker. I wish we had these tools a long time ago.

Update: Branch merged to trunk. Thanks to Dan for the heads-up in comments.

Fun With Digraphs

Christ, I can't believe this compiles-

%:include <stdio.h>
%:include <Cocoa/Cocoa.h>

int main()
<%
    NSString *message = @"Hello, world";

    printf("%s\n", <:message UTF8String:>);

    return 0;
%>

It's section 6.4.6 in the C spec. Good stuff for playing jokes on coworkers, but please don't ship code like this.

Tapuless

Jobs come and go, as do the companies that provide them.

Friends stick around, and solid engineering outlives the engineer.

I'll give you one guess who I'm betting on.

For the Record

Brent Simmons DID NOT get arrested- he paid for that case of Bud.

The World's Toughest Programmer and I DID steal a few Buds from Brent. We also WERE NOT arrested.

There did seem to be MORE red lemur shirts than Apple Engineer shirts.

Kevin Ballard DID shave his beard on a dare.

I DID lose every game of pool I played last week.

She was not a "14-year-old" friend- she was an old friend I hadn't seen since we were 14.

Add your own records in comments if desired.

Where In SF Is Blake?

Find me if you can :)

Resistance Is Futile

I'm pleased to announce that I've accepted a job offer from Microsoft. I can't wait to shuffle off the coil of Objective-C and revel in the awesomeness that is C# and .NET.

Also, you Mac developers were getting a little smug for my taste. See ya, suckers!

24 Days

I was a little bit off, but here it is.

I Did Not Know That

Xcode's Cocoa project templates have 2 occurrences of "#import <Cocoa/Cocoa.h>"- One in the prefix file and one in main.m. The behavior of #import means that only the first occurrence actually matters, but then why would I need the second one in main.m? It turns out that in a monochrome world, I don't. But if you're like me and you use syntax coloring at all, deleting the unnecessary #import in main.m(and any other source files) will leave you with not-so-pretty coloring of all the Cocoa bits.

I'm guilty of deleting the unnecessary #import on general principle, and I'm guessing somebody else out there has done this as well.

Update: I'm now unable to reproduce the syntax coloring problem by deleting the unnecessary #import. However, the problem did exist for myself and others, and was fixed by adding the #import back to a source file. I guess the advice here is: If you have coloring issues and the #import is missing, add it back.