I’m going to Apple.

This is not as exciting for me as it would be for someone else. I actually grew up in Cupertino, and I’ve interned there a few summers ago. I have a lot of respect for Apple’s emphasis on design and quality in their products (there are always exceptions, but the general trend is very good), but I haven’t been dying to work there the way some people might.

What is exciting is what I’ll be doing. As I mentioned a few weeks back, I’ve shifted away from Cocoa development and gotten involved with Clang. I’m happy to say that the group I’ll be joining at Apple is one of the Clang teams, which is primarily responsible for the static analyzer, among other things.

Edit from the future: I now work on Swift.

What does Clang do for you? If you develop for Mac or iOS, it’s probably your compiler these days. The Objective-C language group just brought you collection literals, numeric literals, and boxed expressions, something that’s been wanted for a while. (I wouldn’t be surprised if NSValue wrappers came soon as well.)

NSViewAnimation *anim = [[NSViewAnimation alloc] initWithViewAnimations:@[
    @{
        NSViewAnimationTargetKey: updateBar,
        NSViewAnimationEndFrameKey: [NSValue valueWithRect:updateFrame]
    },
    @{
        NSViewAnimationTargetKey: mainView,
        NSViewAnimationEndFrameKey: [NSValue valueWithRect:mainFrame]
    }
]];

On the static analysis side of things, Clang has long detected memory leaks in your code, even if you’re using ARC. (This only really happens when you cross the Cocoa/CoreFoundation interface, though.)

NSImage *icon;
if ([self shouldUseApplicationIcon]) {
    icon = [[NSImage imageNamed:NSApplicationIconName] copy];
    [icon setSize:NSMakeSize(16, 16)];
} else {
    icon = [NSImage imageNamed:kWarningIconName];
}
return icon;

warning: Potential leak of an object stored into ‘icon‘

But we’re pushing it further. Did you know the analyzer can check for returning stack-based memory?

dispatch_block_t getPrintBlock (const char *msg) {
    return ^{
        printf("%s", msg);
    };
}

error: returning block that lives on the local stack

And even if you aren’t interested in statically finding path-sensitive bugs in your program, Clang can still help you simply with its quality error messages.

size_t getLength (std::string *s) {
    return s.length();
}

error: member reference type ‘string *’ (aka ‘basic_string<char> *’) is a pointer; maybe you meant to use ‘->‘?

What’s that, you don’t use a C-based language? While I might not be helping you, there are a number of other projects that use the same LLVM backend as Clang. I won’t be directly working on that, but it’s shared infrastructure.

(What’s that, you’re not a programmer? Sorry to have wasted your time, then.)

DOWNSIDE: Webmailer and Keystone probably aren’t going to be able to continue. Despite being open-source, they may still present a conflict of interest with working at Apple. (Keystone in particular is kind of “sticky” given how it injects itself into Safari.) Consequently, I’m working to resolve the few outstanding feature requests now and upload the latest version of the source to both apps on Github, but there will most likely be no Mountain Lion update from Belkadan Software.

In addition, this blog is probably a bit sensitive, and while I’d like to continue posting about interesting bits of programming and things Clang is (publicly) supporting, I’m not sure if I’ll be able to do that either. We’ll see.

However, you can also continue to see me on the Clang mailing lists, and hopefully I’ll be working on something that simply makes life easier for programmers. There are a lot of ways we can make the experience of software development better, easier, and smoother. That’s what I’m doing.

I’m going to Clang, and it’s going to be great.

This entry was posted on May 16, 2012 and is filed under Personal. Tags: Meta, LLVM, Apple