Yet Another Mac Dev Blog

Valgrind

2008-10-14T21:11:00.000-07:00

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

2008-09-08T21:47:00.000-07:00

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

2008-08-26T21:23:00.000-07:00

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

2008-06-15T11:05:00.000-07:00

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?

2008-06-09T00:12:00.000-07:00

Find me if you can :)

Resistance Is Futile

2008-04-01T18:33:00.000-07:00

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

2008-01-24T17:50:00.000-08:00

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

I Did Not Know That

2008-01-10T14:30:00.000-08:00

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.

The Leopard Ate My Code

2007-11-05T18:42:00.000-08:00

or: How I Learned to Stop Worrying and Love the Leopard

Since Tiger appeared, many people have been jumping through some interesting hoops to get the iTunes-style "inset" text appearance in metal windows. Some people draw the text twice, where the first drawing is a lighter color and offset down by one pixel. Others are now apparently resorting to image editing products to get a similar result. I've mentioned elsewhere that drawing the text twice is not necessary, and now it gets even easier with Leopard.

Update: Ken points out in a comment that drawing the text twice can have better results than using NSShadow on Tiger. It's still much easier on Leopard.

Here's a simple way to do it on Tiger, using attributed strings and NSShadow:

NSTextField* textField = something from IB;
NSShadow* textShadow = [[NSShadow alloc] init];

[textShadow setShadowColor: [NSColor
    colorWithCalibratedRed: 1.0 green: 1.0 blue: 1.0 alpha: 0.5]];
[textShadow setShadowOffset: NSMakeSize(0.0, -1.0)];
[textShadow setShadowBlurRadius: 0.0];

NSMutableAttributedString* newString =
    [[NSMutableAttributedString alloc] initWithAttributedString:
    [textField attributedStringValue]];

[newString addAttribute: NSShadowAttributeName value: textShadow
    range: NSMakeRange(0, [newString length])];
[textField setAttributedStringValue: newString];
[newString release];

Not too bad, although the color values, pixel offset, etc. are hardcoded. Now let's see how much code it takes to achieve a similar result in Leopard:

[[textField cell] setBackgroundStyle: NSBackgroundStyleRaised];

Nice.

Speaking of Backtraces

2007-09-05T20:55:00.000-07:00

Words escape me.

The Case of the Missing Stack Frames

2007-09-04T21:10:00.000-07:00

Our friend Peter Hosey recently mentioned a problem that frequently makes debugging crash reports harder than usual. The problem is that stack traces don't always display every stack frame in the call chain, which can make it difficult or impossible to determine the flow of control that led to the crash. Let's look at a demonstration of the problem, its causes, and its solutions.

Update: I probably should have mentioned this before- optimizations make debugging hard. Debug builds should not use any optimizations at all, unless you enjoy headaches. With no optimizations in place, your debug builds will not suffer from missing stack frames. This post is intended to help developers who have received crash reports from users testing release builds, where optimizations have been made.

Note: I'll be using only the x86 assembly in this post. If anyone is interested, let me know and I'll post the ppc equivalents in a followup post.

A sample app:

int func2(int x)
{
    return x - 1;
}

int func1(int x)
{
    int result = func2(x);
    return result;
}

int main(int argc, const char** argv)
{
    return func1(1);
}

Here's what that looks like when compiled with no optimizations(-O0):

_func2:
    +0  00001f7e  55                      pushl       %ebp
    +1  00001f7f  89e5                    movl        %esp,%ebp
    +3  00001f81  83ec08                  subl        $0x08,%esp
    +6  00001f84  8b4508                  movl        0x08(%ebp),%eax
    +9  00001f87  83e801                  subl        $0x01,%eax
   +12  00001f8a  c9                      leave
   +13  00001f8b  c3                      ret

_func1:
    +0  00001f8c  55                      pushl       %ebp
    +1  00001f8d  89e5                    movl        %esp,%ebp
    +3  00001f8f  83ec18                  subl        $0x18,%esp
    +6  00001f92  8b4508                  movl        0x08(%ebp),%eax
    +9  00001f95  890424                  movl        %eax,(%esp,1)
   +12  00001f98  e8e1ffffff              calll       _func2
   +17  00001f9d  c9                      leave
   +18  00001f9e  c3                      ret

_main:
    +0  00001f9f  55                      pushl       %ebp
    +1  00001fa0  89e5                    movl        %esp,%ebp
    +3  00001fa2  83ec18                  subl        $0x18,%esp
    +6  00001fa5  c7042401000000          movl        $0x00000001,(%esp,1)
   +13  00001fac  e8dbffffff              calll       _func1
   +18  00001fb1  c9                      leave
   +19  00001fb2  c3                      ret

Standard stuff- main calls func1, func1 calls func2. Each function's prolog pushes the base pointer onto the stack, saves the previous stack pointer as the new base pointer, and updates the stack pointer as needed for that function. And each function's epilog uses the 'leave' instruction to copy the base pointer back to the stack pointer, and pop the the old base pointer back into %ebp before returning control to the calling function. Because these functions perform this standard housekeeping, gdb can provide us with an accurate backtrace if we ask for it:

Breakpoint 1, 0x00001f84 in func2 ()
(gdb) bt
#0  0x00001f84 in func2 ()
#1  0x00001f9d in func1 ()
#2  0x00001fb1 in main ()

So far, so good. Now let's crank up the optimization level to -O2:

_func2:
    +0  00001f8e  55                      pushl       %ebp
    +1  00001f8f  89e5                    movl        %esp,%ebp
    +3  00001f91  8b4508                  movl        0x08(%ebp),%eax
    +6  00001f94  83e801                  subl        $0x01,%eax
    +9  00001f97  5d                      popl        %ebp
   +10  00001f98  c3                      ret

_func1:
    +0  00001f99  55                      pushl       %ebp
    +1  00001f9a  89e5                    movl        %esp,%ebp
    +3  00001f9c  5d                      popl        %ebp
    +4  00001f9d  e9ecffffff              jmpl        0x00001f8e

_main:
    +0  00001fa2  55                      pushl       %ebp
    +1  00001fa3  89e5                    movl        %esp,%ebp
    +3  00001fa5  c7450801000000          movl        $0x00000001,0x08(%ebp)
   +10  00001fac  5d                      popl        %ebp
   +11  00001fad  e9e7ffffff              jmpl        0x00001f99

Now we have a problem.

Each function still has the usual prolog, but the epilogs have changed. There are no 'leave' instructions, and there's only one 'ret' instruction, in func2. gdb is now unable to give us an accurate backtrace:

Breakpoint 1, 0x00001f91 in func2 ()
(gdb) bt
#0  0x00001f91 in func2 ()
#1  0x00001f72 in _start ()
#2  0x00001e99 in start ()

The stack frames from main and func1 are no longer visible in the backtrace(_start calls main in every application, though gdb may sometimes exclude it from the backtrace).

There are two differences that we should note:

• The mechanism by which one function transfers control to another function has changed. Under -O2 optimization, 'calll' has been replaced with 'jmpl', which is sometimes referred to as a tail call optimization.
• Each function now pops the stack into %ebp before transferring control to the called function.

These differences have these results:

• The return address is not updated across function calls, because 'calll' is not used(%eip is not pushed onto the stack).
• %ebp retains its original value across function calls, because the caller pops %ebp(after it pushes %ebp in its prolog) before transferring control to the called function.

Because of these changes, gdb is unable to give us an accurate backtrace. The specific flag that causes this code generation is -foptimize-sibling-calls, which is included in -O2 and higher.

Depending on our needs, there are two ways to disable this optimization.

• The sledgehammer: -fno-optimize-sibling-calls will prevent gcc from generating the problem code across the entire executable.
• The scalpel: Inserting an extra line of code in a function will prevent gcc from generating the problem code on a per-function basis:

int func1(int x)
{
    int result = func2(x);
    __asm__ volatile("");
    return result;
}

The asm directive tells gcc to insert whatever text we specify into the intermediate assembly file before it gets passed to the assembler. Luckily, gcc does not parse our string(s), so it has no idea what logic, if any, that we're adding. Since it appears to gcc that there is additional logic after the function call, the tail call optimization is no longer possible. ~~The 'volatile' keyword prevents gcc from moving the asm directive from its current location in the function.~~

Update: The volatile keyword only prevents the compiler from moving the asm block relative to other asm blocks, not relative to other lines of C code. The above use of 'result' after the asm block is the more important detail of this code snippet. The volatile keyword is not in fact needed, and this hack is a bit more fragile than I originally thought.

There is one other optimization that can result in missing stack frames: -fomit-frame-pointer. gcc's man page doesn't seem to explain which optimization levels can include this flag, but it's easy to disable it entirely with -fno-omit-frame-pointer. Another issue with -fomit-frame-pointer is that it only results in missing stack frames on some architectures. I'll leave it to the reader to explore that one.

So Long, Chicago

2007-08-24T14:47:00.000-07:00

I enjoyed my summer in California so much that I've decided to stick around. While I won't shed a tear for the weather, I'll miss all my friends at CAWUG and PSIG, but I'll try to make up for it at the Silicon Valley CocoaHeads meetings.

<rant>
If you're a Cocoa programmer and you don't attend these regular meetings in your area, you owe it to yourself to start attending now. They are a refreshing vacation from the bleak Windows landscape, and I'm living proof that they can be an excellent career move.
</rant>

Many thanks to Wolf, Bob Frank and everyone else for the memories. I'll try to drop in when I can...

Choices and Repercussions

2007-06-30T02:31:00.000-07:00

People want better phones, apparently.

Ryan Overdevest, a 22-year-old student on a summer internship at an equity research firm, was third in line at the AT&T Store. [...] “I’m here for my boss. He sent me here as soon as I got in.” Overdewest showed up for work at 6 a.m., and was in line by 6:30 Friday morning.

Sucks for Ryan. As a summer intern, I slept way past 6 AM, did some work, had some fun, and then went to a local Apple store to witness the iMadness firsthand.

This is why I didn't major in equity research.

Apologies, More Posts Soon...

2007-06-26T22:29:00.000-07:00

Forgive me, folks- there's barely enough time to keep up with the latest iPhone hype/bashing/speculation/foolishness, and I can't seem to get any posts together lately. Maybe next week.

Meanwhile, let's all chip in and send Gruber some ink for his jackass stamp. He won't last the next 3 days without us...

Another True Story

2007-06-09T22:53:00.000-07:00

Me: "blah blah Jonathan Schwartz blah."

My Friend: "Who?"

Me: "My Little Pony."

My Friend: "Oh."

C is to Wolf as D is to Goat

2007-05-31T22:54:00.000-07:00

Z1, A2, B3, C4, D5, E6, F7, G8...

WWDC Anyone?

2007-05-20T20:00:00.000-07:00

I'm going this year, and I've been told there may be others in attendance as well. If you are one such other and you share my interest in beer and/or whiskey, gimme a shout here.

Update: Either I will be alone at WWDC or I'm the only alcoholic who reads my blog.

Display Eater Update

2007-05-09T23:13:00.000-07:00

We had some interesting discussions with Reza recently, and I thought I should check in with him. Let's see what he's up to:

http://www.reversecode.com/

It now redirects to sio.midco.net, and I find myself in the awkward position of introducing the blogosphere to LED pron. (I'm too scared to download the dmg.)

Hopefully, Reza's site got hacked. I can't even imagine the alternatives.

Reza, feel free to comment here and let us know what's going on.

Update: The LED pron has been replaced by weed pron and the previous URL is 404. Still waiting for Reza to reply here...

Run, Forrest, Run!

2007-04-23T21:03:00.000-07:00

One day, for no paticalar reason, I started runnin. I ran all the way to the end of Chicago. And since I run that far, I kept on runnin, clear across the great state of Illinois. And you know what? I ran all the way to California, and got me a internship at some fruit companay.

I sure hope Jennay can come visit me. I hear they have lotsa them special cigarrets she likes so much.

Update: Ridiculous Fish beats me at my own movie-referencing game, and 10 days earlier to boot. If my calculations are correct, this will inspire a wildly popular Forrest Gump/LOTR mashup that youtube will promptly delete.

C'mon In, The Water's Fine.

2007-04-18T22:50:00.000-07:00

A big warm welcome to CodeBeach.

The goal of this site is to create a central repository where Mac developers can share pieces of useful code (like custom controls, formatters, categories) which is easier to search/use than forums or mailing lists.

This is way overdue. An OS X opensource public domain repository of freely re-usable code, with no bullshit licenses to muck things up. These guys have the right idea, and I urge everyone to contribute what they can, if at all possible.

Many thanx to briksoftware for creating this.

How To Tell If You're A Mac Geek

2007-03-28T21:13:00.000-07:00

When a cute girl says she's interested in studying computer science, she goes from cute to pretty.

When she whips out a MacBook Pro, she goes from pretty to beautiful.

When she mentions that she's a certified Apple hardware tech, she goes from beautiful to fucking gorgeous.

True story. Disturbing, but true.

The BOOLs, They Do Nothing

2007-03-23T00:54:00.000-07:00

From <CarbonCore/MacTypes.h>:

// kInvalidID  KernelID: NULL is for pointers as kInvalidID is for ID's

#define kInvalidID 0

So I should say-

if (someID == kInvalidID)

instead of-

if (!someID) ?

OK yea, I'll get right on that.

Seriously, every time i start to think that NS X rocks, I find some lameass redefinition like this. Zero is zero- am I missing something? Is this really just a Carbon relic, as the filename implies? Is it going away soon?

Obfuscated Me

2007-03-13T21:13:00.000-07:00

So I was over at Scott Stevenson's internet recently and was surprised to see not only my name, but an eerily spot-on description of me:

Now Blake, on the other hand; he's a riddle wrapped in a mystery inside an enigma passed to an instance of NSInvocation.

The only thing Bagelturf missed was that I'm usually just invoked with performSelector: - I'm not very complicated. As for the riddle, it's just @encode().

A Tale of Two CPUs

2007-03-08T22:25:00.000-08:00

Exploring and comparing "Accelerated Objective-C Dispatch" on PPC and x86

Links to Darwin source in this post require an Apple ID. They're free, so get one.

I learned about the Obj-C runtime pages last year, and was reminded by this post to one of Apple's mailing lists. Mr. Maebe did a great job of explaining things, but there's always more to the story.

Who 0xfffeff00 is

Mr. Feffoo is a copy of the _objc_msgSend assembly routine defined in objc-msg-ppc.s. As Mr. Maebe pointed out, the only documentation is the source code. The easiest way to find it is to google 0xfffeff00. Apple's policy of requiring a login to view their source code seems to keep google's spider at bay, but our old dead friend, DarwinSource, is still cached. The first found occurrence of 0xfffeff00 is in objc-rtp.h.

<side note>
While we're looking at _objc_msgSend, I'd like to remind everyone who says "messaging nil objects returns nil" that our friend Peter Ammon showed us that this is not always the case. If your code makes that assumption, it wouldn't hurt to fix it now.
</side note>

Notice that this is the PPC version of Darwin. 0xfffeff00 is the value assigned to kRTAddress_objc_msgSend, but only for PPC. While this header file is very interesting, its associated source file is the real fun:

/*
  objc-rtp.m
  Copyright 2004, Apple Computer, Inc.
  Author: Jim Laskey
  
  Implementation of the "objc runtime pages", an fixed area 
  in high memory that can be reached via an absolute branch.
*/

Hat's off to Mr. Laskey for this file. In my opinion, what happens herein is some of the most interesting code in Darwin. I'll leave it to the reader to enjoy the code that actually copies the _objc_msgSend routine to high memory. Code that treats code like the data it is always makes me smile.

PPC Limits Set

The magic number here is 0xffff8000. Above this address lie the "comm pages", the documentation for which eludes me now(anyone?). The reason this address is important is that a PPC absolute conditional branch can reach any address at or above it, thereby allowing the OS or kernel to copy some commonly used functions to those virtual memory pages.

In the Programming Environments Manual, 'bc', 'bca', 'bcl', and 'bcla' instructions are defined as having a 14 bit address field concatenated with two low zero bits, so that the destination address is guaranteed to be a multiple of four. That means that this is effectively a 16 bit address field. While 'bc' and 'bcl' have their charms, we're more interested in the absolute variants.

If we set the high bit, or sign bit, of the address field and clear the lower bits, the CPU's sign extension produces the number 0xffff8000. And if we use the absolute variants 'bca' and 'bcla', we can branch to that address directly(as opposed to our current address minus 0x8000).

PPC Limits Broken

The comm pages are nice, but they're already used for standard ANSI and/or Unix C functions, not Apple's Obj-C stuff. So how does Apple implement similar behavior for common Obj-C runtime routines like _objc_msgSend?

Simple- build more comm pages below the ones that already exist, and use a branch instruction with a broader range that can reach those addresses.

Assuming you're viewing the conditional branch documentation in the PEM, scroll up a bit to the unconditional branch instructions, specifically 'ba' and 'bla'. Notice the 24 bits available in the destination address field. This field is also concatenated with 2 low zeroes, which effectively gives us 26 bits. (Sure, we could use 'bcctr' to get a full 32 bits, but that would require 2 extra instructions to load the address and would clobber the count register.)

So, if we sacrifice the ability to branch conditionally, we gain 10 bits, or 1024 bytes of addressability*. If we use the unconditional branch instructions, we can branch to anywhere at or above 0xfe000000, which is well below the addresses of the routines defined in objc-rtp.m.

Jackpot.

The _objc_msgSend assembly routine is copied into high RAM at launch time, and PPC code that was compiled with Xcode's "Accelerated Objective-C Dispatch" option uses the high-RAM version of _objc_msgSend instead of the usual symbol stub.

Intel Wins For Once

I don't like x86 assembly and machine code any more than the next guy, but here's something that doesn't suck about the Intel chips:

Darwin x86 has no runtime pages, because it doesn't need them. Not being able to load a 32 bit number in a single instruction is a limitation of the PPC ISA that Intel doesn't share. x86 Obj-C code is "accelerated" by design, and the "Accelerated Objective-C Dispatch" option has no effect whatsoever. Since they don't need symbol stubs, they don't need the "accelerated" workaround.

It's not inconceivable that the "Accelerated Objective-C Dispatch" option will only exist for as long as Apple supports PPC machines.

One More Thing™

Though it's only loosely related to this article, it's interesting to note the following code from objc-rtp.m:


 // initialize code in ObjC runtime pages
 rtp_set_up_objc_msgSend(kRTAddress_objc_msgSend, kRTSize_objc_msgSend);
    
 rtp_set_up_other(kRTAddress_objc_assign_ivar, kRTSize_objc_assign_ivar,
  "objc_assign_ivar", objc_assign_ivar_gc, objc_assign_ivar_non_gc);

An entire function to assign a value to an instance variable? And an optimized version at that? Hmm.

While I currently have no NDA obligation with Apple, I've been told that the information at which this code hints is hush-hush for now. So, out of respect for The Masters, I will only direct the reader to Xcode's "Project Settings" window. Specifically, the description of the "-fobjc-gc" flag.

For those who don't want to fish around for details, "gc" stands for "Great Code".

Many thanks to Mr. Laskey, Mr. Ammon, and all of the Apple coders working on the Obj-C runtime. Our applications only execute correctly and easily because you have all applied an enormous effort in designing a crucial part of the OS X underbelly. We all appreciate your work.

If any of you attend C4[1], the drinks are on me.

* I meant to say 33,521,664 bytes, not 1024 bytes. Minor oversight, sorry about that.

Free Noob Lesson #2

2007-03-05T23:28:00.000-08:00

We've all done this-

- (id)init
{
    if (!(self = [super init]))
        return nil;

    // etc.
}

That obviously returns nil when [super init] fails.

But what if you accidentally add(or forget to remove) an extra semicolon?

- (id)init
{
    if (!(self = [super init]));
        return nil;

    // etc.
}

GCC is perfectly happy with that, but your application is not. The above code reduces to this useless logic:

- (id)init
{
    self = [super init];

    return nil;
}

One might say that we could avoid this by returning self instead of nil, but then the code in 'etc.' would still never be executed, and the resulting bug would probably be much harder to locate.

The only quick and easy protection that I can think of is sobriety, which is clearly out of the question. Any thoughts?

Open Letter Regarding Display Eater

2007-02-25T23:31:00.000-08:00

To Reza Hussain:

There is a lack of official information about versions of Display Eater that predate version 1.85, which is the version I decompiled. You were interviewed by a Swedish web site, and allegedly provided the information we are looking for, but the English translation of that interview is currently only available through a third party.

Reza, I respectfully request an answer to this question:

Did previous versions of Display Eater delete files and/or folders other than your own Application Support folder?

I recognize that version 1.85 only deletes files that your app created, and I only ask this question to provide facts to the Mac community, and to conclude this sad chapter of our shared history.

Be assured that I am not interested in harassing you, whatever your answer may be. We just want to know the truth. In the interest of preserving what is left of your good reputation, please enlighten us, in English.

Thank you.

To everyone else:

The comments to this post are reserved for Reza, and polite commenters. Inflammatory comments will be removed, as there are countless other outlets for those sentiments.

Thank you.

Behind The Curtain With Display Eater

2007-02-24T23:43:00.000-08:00

You may have seen the discussion recently about an app called Display Eater by Reza Hussain. ~~While the author has not responded to the latest discussion, he allegedly admitted that the whole thing was a hoax to deter potential pirates.~~ Reza has just replied with a public letter. While the discussion has been lively, the investigation has been nonexistant. So here it is.

First, the legal stuff:

According to the Display Eater 1.8.5 license agreement:

3. License Restrictions
b. You may not alter, merge, modify, adapt or translate the Software, or decompile, reverse engineer, disassemble, or otherwise reduce the Software to a human-perceivable form.

But I wanted to disassemble the app! Fortunately, the license is not really a legal agreement:

THIS SOFTWARE END USER LICENSE AGREEMENT(EULA) IS A LEGA AGREEMENT BETWEEN YOU(EITHER AN INDIVIDUAL OR, IF PURCHASED OR OTHERWISE AQUIRED BY OR FOR AN ENTITY, AN ENTITY) AND THE AUTHOR OF THIS SOFTWARE.

Since LEGA AGREEMENTs don't hold up in court, we're free to do what we want with the app*. I'd also like to suggest to John Stansbury that while his assertion that users don't have the right to reverse engineer an app is correct in most cases, it's not applicable here, for the above reason.

Reza, fix your license.

Second, the fun stuff:

This is one of those apps that writes copious amounts of crap to the console for no reason. For example, after simply launching the app, declining to register, and quitting, I got this:

display_eater[3338] help me Start Recording
display_eater[3338] no file
display_eater[3338] mmmkay
display_eater[3338] mmmmm
display_eater[3338] selfmutilation DVC PAL
display_eater[3338] lettesta /Applications/Display Eater 1.85/Display Eater.app/Contents/Resources/cursor2.gif
display_eater[3338] onenationunderfuck 640x480
display_eater[3338] cheated--20 fps
display_eater[3338] loadedrender

Yes, that says onenationunderfuck. In my console log. Is it still cursing if you don't use camelCase? Well, at least he's a South Park fan. Here are a few other nice ones I found in the disassembly:

This "emailDeveloper:" method doesn't actually send any mail, but at least it further pollutes my log.

-(void)[mainWindowController emailDeveloper:]
3c600003    lis      r3,0x3
38639500    addi     r3,r3,0x9500     emailz0r
4801e6d8    b        0x21bd0          _NSLog

And from other methods:

386395e0    addi     r3,r3,0x95e0     FATTTTTTTTTY>>>>>>>
4801e005    bl       0x21bd0          _NSLog

386395a0    addi     r3,r3,0x95a0     not saved lol
4801e1a1    bl       0x21bd0          _NSLog

3863a5a0    addi     r3,r3,0xa5a0     lawl
4800f438    b        0x21bd0          _NSLog

3863b2c0    addi     r3,r3,0xb2c0     OMGFWTFBBQxinFINITY
48003ee8    b        0x21bd0          _NSLog

38639e60    addi     r3,r3,0x9e60     SDKNLLLLLLLLLLLLL
480161d5    bl       0x21bd0          _NSLog

And on and on and on. People, mescaline can be loads of fun, but it's not conducive to a healthy programming environment.

Ok, so Reza likes to make jokes at the expense of my log file, but that's not a capital offense. Allegedly deleting user data should be. While we're talking about spurious log data, I should note that Display Eater actually logs the customer's name, email and serial number on every launch. I'll give you one guess why that's a Bad Idea™.

Finally, the good stuff:

Ok, so Reza beat me to the punch by admitting that Display Eater does not really delete your home directory. But it does delete something, and those users who watch their console logs already know what it is. I had planned to present the complete annotated assembly of the methods involved, but that would bloat this post incredibly and bore most of you. Here's a higher level explanation:

The C function that does the deleting is called "destroy". In otool or otx output, search for "_destroy:". Its C declaration would look like this:

void destroy(NSString* inString);

It is called only from itself, and from one Obj-C method in the "recordCreateController" class:

- (id)addRecordWithPath: (NSString*)inPath
                andRect: (NSRect*)inRect;

(class-dump says inPath should be of type "id" but the code in Display Eater assumes an NSString*. We'll have to wait for the GPL'd code, but I suspect this is just more sloppy code- see below for the rest)

In the disassembled code, "addRecordWithPath:andRect:" immediately follows "_destroy:".

Note the interestingly named "emptyEntireClipOnAllOfThem" that follows "addRecordWithPath:andRect:". While it smacks of gangland violence, it is not involved with deleting any files. My good conscience prevents me from revealing its purpose :)

So, when does "addRecordWithPath:andRect:" call "destroy"? The Obj-C code looks something like this:

    id  delegate = [[NSApplication sharedApplication] delegate];

    // Reza, you may want to call [delegate respondsToSelector:] first...
    NSString*   support = [delegate applicationSupportFolder];

    // "ninjakiller" is the reg file.
    // Reza, use stringByAppendingPathComponent, mmmkay?
    NSString*   regFile = [support stringByAppendingString: @"/ninjakiller"]
    NSArray*    regArray = [NSUnarchiver unarchiveObjectWithFile: regFile];

    if (![[regArray objectAtIndex: 1] compare: @"Special [K]"] ||
        ![[regArray objectAtIndex: 1] compare: @"KCN"])
    {
        NSLog(@"BUT I FALTER");
        destroy(@"~/Library/Application Support/display_eater/");

        // and then show the pirate dialog...
    }

Ok, nothing surprising. Whoever Special [K](nice name, btw) and KCN are, they're screwed. So what happens inside "destroy"? It seems clear already that Display Eater's app support folder will get nuked, but is that all that happens?

void destroy(NSString* inString)
{
    NSFileManager*  manager = [NSFileManager defaultManager];

    NSString*       path = [inString stringByExpandingTildeInPath];
    // Believe it or not, 'path' is only used for the following call.

    NSArray*        files = [manager directoryContentsAtPath: path];
    unsigned int    curFile; // I assume this is unsigned.

    for (curFile = 0; curFile < [files count]; curFile++)
    {
        // Reza, you've already expanded this- you don't need to do it twice.
        NSString*   basePath = [inString stringByExpandingTildeInPath];
        NSString*   curFileName = [files objectAtIndex: curFile];

        // Reza, please use stringByAppendingPathComponent.
        NSString*   curPath = [NSString stringWithFormat: @"%@/%@"
            basePath, curFileName];

        NSLog(@"%@", curPath);

        // Reza, you did this already...
        NSFileManager*  manager2 = [NSFileManager defaultManager];

        // ...and this, too.
        // I'm not sure why passing just the name and not the path works,
        //   but it does.
        if ([manager2 isDeletableFileAtPath: [files objectAtIndex: curFile]])
        {
            // Calling default manager yet again. At least we're using
            //   the full path this time.
            [[NSFileManager defaultManager]
                removeFileAtPath: curPath handler: nil];
            NSLog(@"DELETABLE");
        }
        else
        {
            destroy(curPath);
        }
    }
}

So there it is. Display Eater recursively deletes the contents of its own Application Support folder(but not the folder itself), and nothing else. If the user was silly enough to put anything in that folder, it would have been nuked. But in that case, one might argue that they deserved it.

Note that the "piratekiller" file, whose contents seem to indicate a perverted TCL function call(kilo transform ar reza) is never used for anything.

Ultimately, the worst thing about this app is the sloppy Obj-C code. Reza, I would be happy to optimize your code a bit, if you're so inclined.

* I'm no lawyer- if anyone can prove me wrong about this point, please do so.

Another Link Post

2007-02-22T22:41:00.000-08:00

Lately, I've had better luck with links than real info, and I've recently come across a webcomic that most of you will enjoy. Here's a taste. OK, one more. And be careful hopping off the bus, Gus.

Recommended usage: Go to the main page and continue hitting the 'prev' button until your boss/wife/parole officer starts asking questions.

Many thanks to whichever Mac dev shared that site with me via their del.icio.us bookmarks. Sorry I don't remember who it was.

Some BOOLs Have All The Luck

2007-02-20T21:47:00.000-08:00

ALERT: This post has been proven wrong. It remains here as a badge of shame. Continue reading for entertainment purposes only!

A quick note, since something just bit me in the ass, and some of us dislike unsolicited ass-biting. Disclaimer: I'm using XCode 2.2 and whatever gdb was current then- this may have been fixed since then.

I had a BOOL member/instance variable, we'll call it myBool. I set it like so-

myBool = someInt == someOtherInt;

And all was well in both debug and release targets. Then I changed the scope of the member/instance variable to global, outside of any class, as in-

static BOOL myBool;

After doing so, the boolean expression above evaluated to false/NO, regardless of the values of the 2 ints. I watched it happen in XCode's debugger window, it was awesome.

After several forceful introductions of my keyboard and my forehead, I tried a silly test that shouldn't matter at all, and it worked.

myBool = (someInt == someOtherInt);

I compiled and disassembled both versions of my release and debug targets, hoping for a most excellent blog post, and was greeted with identical code all round. So the problem appears to be that my version of gdb has different rules for evaluating boolean expressions, depending on the scope of the receiver of the expression. Global variables require a parenthesized expression while member/instance variables do not.

One guess who will be parenthesizing more than usual in the future.

And sorry, Wolf. The Rod Stewart reference was too good to pass up :)

Update: Victoria Wang, who I met at PSIG 101, posted an amusing quote about parentheses from one of her 'CIS' professors(Computing and Information Systems?)

"Some teachers go crazy when you use parentheses on an expression that's going to be evaluated first anyway. I don't care. It's like wearing a belt, and suspenders too!"

So, did gdb swipe my belt or my suspenders? And can I set a watchpoint on my fly?

Cheers, Victoria, and thanks to Wolf for the link.

Update 2:
After a restart, Xcode is no longer exhibiting the strange behavior. Maybe something was corrupt, I don't know. Sorry for the false alarm. It is now safe to reenter the building.

Show A Brotha Some Love

2007-02-14T19:14:00.000-08:00

My boy Karsten just pimped GDB and made copies of his pimp cane available for all of us.

Holla.

God Went And Did It Again

2007-02-07T18:27:00.000-08:00

Finally, the truth about global warming. Those damned scientists were really getting on my nerves.

I don't want this to be a link blog, but this gem was too good to pass up.

Free Noob Lesson

2007-01-30T20:52:00.000-08:00

Unless you have an infinite stack and care not about results, don't call [someView display] inside [someView drawRect:].

Bad dog. No bone.

CSS FTW

2007-01-21T19:15:00.000-08:00

Kam Dahlin asked about my code formatting for the NSViewAnimation post, and I was embarassed to report that I had no special css style for it. So, my friend Mitch stepped up and handed me this:

.source_code, li .source_code {
 padding-left: 2px;
 border-left: 1px solid #666;
 font: 100% Monaco,monospace;
 font-size: 8pt;
 white-space: pre; /* CSS2 */
 white-space: -moz-pre-wrap; /* Mozilla */
 white-space: -hp-pre-wrap; /* HP printers */
 white-space: -o-pre-wrap; /* Opera 7 */
 white-space: -pre-wrap; /* Opera 4-6 */
 white-space: pre-wrap; /* CSS 2.1 */
 white-space: pre-line; /* CSS 3 (and 2.1 as well, actually) */
}

/* change this line to set the width of box */

.source_code {
 width: 100%;
}

/* change this line to set the width of box in a list */

li .source_code {
 width: 100%;
}

Stick that in your css file, and invoke it by surrounding the code text with <div class="source_code"> and </div>. You still have to detab the code first, but it beats the hell out of some &nbsp's. Also note that Blogger will not display the style when you preview a post- you have to submit the post to see it.

Update: Use "pre" instead of "div" and all is well. I can fly through asm but html is a black art to me. Non-thanks to all who failed to correct me earlier :P

a.out of gas

2007-01-13T18:41:00.000-08:00

Gruber says it's not surprising that Apple has OS X compiling and running on something other than PPC or x86. Considering that <mach/machine.h> lists 14 possible processor families, I have to agree with him. But what I find most interesting, assuming that the iPhone uses an ARM CPU, is that Apple is able to target one of the processors that is commented out in that file. If they're targeting ARM, maybe they're using 'gas' from binutils instead of 'as' from cctools...

Fun With Custom Keys

2007-01-12T20:34:00.000-08:00

I was playing around with NSViewAnimation and I wondered why there weren't more predefined dictionary keys. Then I realized that it was just an associative array*, and I could define as many keys as I want, and take the appropriate action in a delegate method. This is probably obvious to most of you, but I just discovered it. So I gotta, you know, blog it.

Here's an example I threw together that lets you swap one view for another after animatedly resizing a window. The most obvious use of this would be in a preference window, when switching between multiple tabs. For the example names, I'm using Wolf Rentzsch's 'NSX' naming convention.

// Define custom objects and keys
#define NSXViewAnimationSwapAtEndEffect @"NSXViewAnimationSwapAtEndEffect"
#define NSXViewAnimationSwapOldKey      @"NSXViewAnimationSwapOldKey"
#define NSXViewAnimationSwapNewKey      @"NSXViewAnimationSwapNewKey"

Then somewhere in your controller class:

    NSRect  newWindowFrame  = someCalculatedRect;

    // Build a dictionary...
    NSMutableDictionary*    windowDict =
        [NSMutableDictionary dictionaryWithCapacity: 5];

    // ...with standard keys...
    [windowDict setObject: myWindow
        forKey: NSViewAnimationTargetKey];
    [windowDict setObject: [NSValue valueWithRect: newWindowFrame]
        forKey: NSViewAnimationEndFrameKey];

    // ...and custom keys.
    [windowDict setObject: NSXViewAnimationSwapAtEndEffect
        forKey: NSViewAnimationEffectKey];
    [windowDict setObject: someViewToHide
        forKey: NSXViewAnimationSwapOldKey];
    [windowDict setObject: someViewToShow
        forKey: NSXViewAnimationSwapNewKey];

    // Create the animation.
    NSViewAnimation*    windowAnim  = [[NSViewAnimation alloc]
        initWithViewAnimations: [NSArray arrayWithObjects:
        windowDict, nil]];

    // Go.
    [windowAnim setDelegate: self];
    [windowAnim startAnimation];
    [windowAnim autorelease];

And finally, the delegate method:

- (void)animationDidEnd: (NSAnimation*)animation
{
    // Standard sanity checks.
    if (![animation isKindOfClass: [NSViewAnimation class]])
        return;

    NSArray*    animatedViews   =
        [(NSViewAnimation*)animation viewAnimations];

    if (!animatedViews)
        return;

    // Grab the window from the first animation.
    NSWindow*   animatingWindow = [[animatedViews objectAtIndex: 0]
        objectForKey: NSViewAnimationTargetKey];

    if (animatingWindow != myWindow)
        return;

    // Iterate through possibly multiple animations.
    UInt32  i;
    UInt32  numAnimations   = [animatedViews count];
    id      animObject      = nil;
    id      keyObject       = nil;

    for (i = 0; i < numAnimations; i++)
    {
        animObject  = [animatedViews objectAtIndex: i];

        if (!animObject)
            continue;

        // Grab our custom effect key.
        keyObject   = [animObject objectForKey: NSViewAnimationEffectKey];

        if (!keyObject)
            continue;

        // Execute the custom effect.
        if ([keyObject isEqualToString: NSXViewAnimationSwapAtEndEffect])
        {
            NSView* oldView = [animObject
                objectForKey: NSXViewAnimationSwapOldKey];
            NSView* newView = [animObject
                objectForKey: NSXViewAnimationSwapNewKey];

            if (oldView)
                [oldView setHidden: YES];

            if (newView)
                [newView setHidden: NO];
        }
    }
}

A trivial example, no doubt, but there are countless possibilities. Imagine calling setDuration: from the animation:didReachProgressMark: delegate to implement some crazy animation curve. Or overriding setCurrentProgress: in a subclass to link several animations more intuitively than with startWhenAnimation:reachesProgress:. Of course, all this is possible without using custom dictionary keys, but this way is a lot more fun.

I'd love to hear any more uses you can think of, and other classes that use dictionaries in a similar way.

*I originally said 'it was just xml', and Peter Hosey pointed out that while the key/object relationship evoked feelings of xml in me, it's not really xml until it's saved to disk. I've updated the text to more correctly describe data in memory.

Score One For Curious George

2007-01-10T20:55:00.000-08:00

My sources in Washington D.C. report that Dubya went to great lengths to schedule tonight's address. From planting moles inside Apple to buying iPods for all of the most influential journalists, no expense was spared. George's plan was executed without a hitch, and his most controversial address to date was carried out at exactly the perfect time.

Here's what was going through his head while he read from the teleprompter:

"I have decided to say 'Fuck You' to 65% of Americans, Gawd knows how many Iraqis, and whoever those guys are who did that report thingy. And probly Congress, too. Since you're all shitting yourselves about the iPhone, you're not even listening to me! Here it comes, bitches- iRock '07! Woohoo! No dictator? No WMDs? Who cares?! We got OS X on a phone!"

Yeehaw, people. 20,000 iRock fans can't be wrong.

The Year of the HIG

2007-01-05T19:23:00.000-08:00

Apparently, when Gruber speaks, people listen. "The HIG Is Dead", his presentation at C4, has sparked an incredible amount of discussion and activity recently. Amidst all the individual stories of developers sprucing up their UIs, Brandon Walkin has organized the Indie HIG. I highly recommend everyone take a look, and get involved if you like the idea. Also, I have an account there, and that makes it even cooler.

It can't be expected to actually replace Apple's HIG, and Brandon says as much on the front page. It's largely a design principle popularity contest, with a bunch of dev types discussing do's and don'ts and occasionally agreeing with each other. And it will never have the authoritative feel of Apple's official docs. Having said all that, it's the best idea I've heard recently, and there's no way around those issues. Unless we can hypnotize Steve Jobs...

Which brings me to another point- Apple's HIG 2.0. I predict this will be the year we see it. Not until WWDC, maybe, but I think Apple is paying attention. I believe the volume of public complaints from developers about the difficulty of maintaining a consistent look and feel has already surpassed Apple's threshold of tuning-out. There have been rumors of more standard controls in Leopard, and standard toolbar icons, etc. and the HIG 2.0 will be a perfect companion.

In the meantime, join us over at the Indie HIG, and throw in your 2 cents. Imagine the stories you can tell your grandchildren when your ideas get rolled into the HIG 2.0...

UPDATE
My first-ever prediction may be comin' up Milhouse. Daniel Jalkut gives me hope. And no, I did not attend the tech talk when it rolled through my town, which was before I posted my prediction.

Can't Touch Nibs

2007-01-03T00:59:00.000-08:00

I heard something recently on the grapevine that I haven't yet seen in the blogosphere, so I thought I should mention it. If there's any demand, I'll dig deeper into the code and post further details.

- Open up Interface Builder, create and save a new blank nib file(Cocoa/Application).
- Locate the new nib in Finder, and 'Show Package Contents'.
- Delete 'classes.nib' and 'info.nib', but leave 'keyedobjects.nib'.
- Attempt to reopen the modified nib package in IB.
- Marvel at IB's reluctance to open the file for editing.

Ok, so IB won't open it, so what?

It turns out that IB's 'Open' command and [NSBundle loadNibNamed:owner:] have entirely different requirements regarding the contents of the nib package we're attempting to load/open.

The reason this came to light was that someone was trying to have a look at XCode 2.4.x nibs, which lack the 2 files we deleted above. I'm not sure when Apple started deleting those 2 files, but on my box(XCode 2.2) I have all 3 internal files in 'PBX.nib' and 'PBXActiveOperationsPanel.nib'. But obviously, since XCode 2.4.x launches with no errors, those 2 deleted files aren't needed at runtime.

So, at first glance, the moral of the story is- you can keep your users from opening your nibs in IB(thus keeping those damned GUI hackers at bay) by simply deleting the aforementioned files from your nibs, possibly with a custom build phase.

But just for fun, we glanced twice.

- Repeat the 'create and save a blank nib file' steps, but this time, don't delete anything.
- Copy 'classes.nib' and 'info.nib' from the newly created nib package into the unopenable nib package.
- Marvel at IB's willingness to open the previously unopenable file for editing.

I am sure that there is some information lost in the translation, but this seems to be a good start. As always, any comments/questions/suggestions are welcome.

Checksum, Please

2006-12-24T18:36:00.000-08:00

I was playing around with file comparisons recently, and I thought I could have some fun with crc32(). It's a common function, so it's probably in the system somewhere already. I asked man about it and there it is, in the 'n' section of the man pages:

DESCRIPTION
This package provides a Tcl-only implementation of the CRC-32 algorithm based upon information provided at http://www.naaccr.org/standard/crc32/document.html If the Trf package is available then the crc-zlib command is used to perform the calculation.

Tcl-only, great. And searching the XCode docs just lead to the same man page. But I couldn't believe there's not a C function in the system somewhere, so I asked google to have a look at the Darwin source, and found this page. Ah, it's part of zlib, as mentioned in the man page description. No wonder Apple has no docs describing it.

So next time you need a 32-bit checksum, add -lz to your linker flags and send me a postcard.

MacMob

2006-12-22T17:11:00.000-08:00

I propose a new Mac software promotion.

For the next few days, participating developers will set aside 20% of their profits and pool the cash. Using the cash, we will procure an assortment of small arms and blunt objects, and hire a P.I. to find the jackass who shat on Aaron's holidays.

Of Balls and Whiners

2006-12-18T21:05:00.000-08:00

I've never been paid to write code, so I'm ill-qualified to form an opinion on the whole MacHeist thing. I do however have a keen eye for idiocy, and one group in particular seems in need of calling-out. To paraphrase:

"Screw you, Gus! You just lost a potential and/or current customer!"

What? Let's try to understand the reasoning behind such a statement, starting with the most illogical.

Possibility the First:
These people actually think there is some correlation between a developer's opinions or attitude and his products. It could happen I guess. If a developer can maintain a list of pirated serial numbers, and make their app not work with them, it stands to reason that they could just as easily maintain a list of apps that have been included in the MacHeist bundle, and make their apps not work when those other apps are installed. And if the developer has balls enough to speak his mind without trying to kiss anyone's ass, he's certainly capable of making his app trash your whole system! Therefore, as cautious consumers and MacHeist fans, we would all do well to avoid apps from that developer.

Possibility the Second:
These people actually think that the revenue lost by their secession will have an impact great enough to make a developer see the error of his ways. That sounds reasonable, maybe. Assuming Flying Meat has fewer than ten paying customers, that's a sizeable chunk of income to lose.

Possibility the Third:
These people actually think that although a single user's threat would have little impact, a concerted effort by many organized users will have the desired effect. So, if we all band together and sign the petition, we can force him to change his ways.

Possibility the Fourth:
These people subconsciously realize that they're bringing nothing to the table and feel embarrassed to burden Gus any longer with all their support issues. The only sensible thing to do is to remove themselves from the picture in a flaming puff of glory.

It never occurred to me before all this, but now I'm wondering: When I'm shopping for software, how much do I care about the developer's personal life? Say the guy sacrifices goats and small children on weekends. Can he write code that makes me do that? No? Ok, then, yea I'll buy his apps. On the other hand, say he keeps his mouth shut when he takes issue with something, to avoid possibly stepping on anyone's toes. I wouldn't respect him quite as much, but I'd still buy his apps.

I guess I shouldn't complain, really. All of the informed opinions on both sides of the issue have given me things to think about that otherwise wouldn't have occurred to me. And the whiners balanced it out with some much needed comedy.

Implicit memcpy(3) calls

2006-12-17T22:46:00.001-08:00

Peter Hosey was kind enough to document the speed difference between malloc() followed by bzero() and calloc(). They are two different ways to allocate and zero a block of memory, but it turns out that calloc() is much faster.

I was wondering how much of that speed difference is the result of having one fewer function call in your code, and that reminded me of a lesson I learned a few months ago...

Some time ago, I picked up the practice of initializing all local variables at their declarations, like:


double aDouble = 0.0;

In many cases, it's not really necessary, and the coders who disagreed with the practice correctly pointed out that I was simply adding extra code and extending the execution time. My reasoning was that not having garbage data in a local variable is worth the extra few cycles it takes to zero an integer or even a double.

At the time, I was a PowerPlant junkie, and would initialize LStrings with Str_Empty or whatever it was called. And all was good.

Since I've switched to XCode, I've been using C strings more than ever before. NSMutableString is great when it's possible to use it, but creating, modifying and releasing a few hundred million of them gets annoying. So I was using lots of C strings and initializing them to zeroed bytes like so:


char aString[1000] = {0};

I knew that only the first byte needed to be zero to qualify the local variable as a null string, but I didn't like garbage data. In addition, if any of my subsequent string handling code accidentally left out the null terminator, it would still be there. It was a win/win situation, and it worked flawlessly.

As it turned out, my adoption of the initialize-blindly-at-declaration practice slowed things down considerably when dealing with C strings. After optimizing all I could, Shark told me that about 55% of my code's running time was spent in memcpy(). At first I thought that was a good sign. After all, I was not calling memcpy() explicitly in my code, so it must have been invoked by printf, scanf, and the like. And I figured that when more than half the time is spent in low level system functions, I've done all I can.

Out of curiosity, I disassembled the app I was working on with otool and searched for "memcpy". Holy shit, it's everywhere. It's not only being invoked from printf/scanf(which Shark would have told me if I had asked). This is when the lesson sunk in- zeroing an entire C string of arbitrary length is a Bad Idea™. gcc translated my harmless {0} into a memcpy call. Combine that with 10 or 20 C strings per method, with each method being called a few million times, and I began to see why memcpy was the latest culprit according to Shark. Although I was not calling memcpy() explicitly, gcc was. A lot.

So I still initalize atomic variables in their declarations, but I'm much more careful when using composite data types. Before typing this post I just used my instinct to decide which way to go. But since Peter was generous enough to provide some empirical data, I may as well follow suit.

Not surprisingly, PowerPC and Intel code behave quite differently. Here's what I found when using the initialize-at-declaration approach for C strings. The following disassembly is modified output from otx.

PowerPC
If the char array is less than or equal to 32 bytes, gcc produces inline load/store instructions. For example, a 16 byte string:


3c400004  lis   r2,0x4
3842ef54  addi  r2,r2,0xef54
80020000  lwz   r0,0x0(r2)
81220004  lwz   r9,0x4(r2)
81620008  lwz   r11,0x8(r2)
8042000c  lwz   r2,0xc(r2)
901e0018  stw   r0,0x18(r30)
913e001c  stw   r9,0x1c(r30)
917e0020  stw   r11,0x20(r30)
905e0024  stw   r2,0x24(r30)

where the data pointed to by 0x3ef54 is a bunch of zeroes, and r30 is a copy of the stack pointer.

If the char array is greater than 32 bytes, gcc inserts a call to memcpy().

Intel
If the char array is less than or equal to 64 bytes, gcc produces inline move instructions. For example, the same 16 byte string:


c745e800000000  movl  $0x00000000,0xffffffe8(%ebp)
c745ec00000000  movl  $0x00000000,0xffffffec(%ebp)
c745f000000000  movl  $0x00000000,0xfffffff0(%ebp)
c745f400000000  movl  $0x00000000,0xfffffff4(%ebp)

If the char array is greater than 64 bytes, gcc inserts a call to either memset() or memcpy().

So apparently, if the length of your C string is more than 16 times the number of bytes your CPU can zero with a single instruction, gcc will insert a call to memcpy(). Moral of the story- only zero the first byte of a C string, unless it's absolutely necessary, or speed doesn't matter.

Belated C4 words

2006-12-16T15:23:00.000-08:00

0xC4 == 196, which is roughly the number of Mac laptops I saw there. I gotta get me one of those. Jokes aside, there were actually 98 attendees, which seems somehow related to 196...

Summaries of the presentations have been posted all over, so I'll just relay my personal experiences. One thing that I noticed was how accessible everyone was. Nobody cared that I don't have any apps out there, or that I asked a lot of stupid questions. A good example would be Wolf Rentzsch. Here's a successful consultant type who's forgotten more than I've learned, and is still totally easy to talk to. I hope I'm that nice when I'm rich and famous. Thanks again, Wolf, for the whole show!

Bob Frank is another good example. Snakebite himself. I chatted with him several times, but he's more into Java, so we didn't have a lot in common. Still, he was more than happy to answer stupid questions.

I also got to chat a bit with Gus Mueller. I had to raise my voice a little because he's approximately 8 feet tall. I think the people insulting him on his blog lately don't know just how big this guy is. Seriously, don't mess with Gus. Nice guy though, and it must have been a good feeling to see at least half of the presenters using VoodooPad.

Speaking of tall, I met Aaron Hillegass. WTF! I was looking up at him even when he was on the other side of the room. Another nice guy. I had fun telling him all about how I hadn't read any of his books, and never heard of the ranch and boot camp, etc.

Actually, that was a recurring theme for me. Hopefully by next year I'll have more experience with some of the awesome apps these guys write. One app that caught my eye was Knox. Marko Karppinen was sitting at my table on day 2, and he showed me all the cool stuff it does. If you need encrypted disk images, give it a shot.

Another guy at my table was Travis Cripps. They say you gotta watch out for the quiet types, and that's him. He knows his stuff, keep an eye out for his apps.

I talked quite a bit with Chris Patterson. Sadly, Chris is currently writing non-Mac code. We met up with one of his coworkers, Daron something, at Jak's Tap after day 1. That was awesome, because we're all former PowerPlant geeks. Beer, multiple inheritance, stack based classes, beer, polymorphism, RTTI, beer. The chicks were diggin it.

That reminds me of the only thing I regret about C4. On day 2 there was a guy sitting behind me who spoke up after every single presentation. Normally I wouldn't have remembered him, but the thing is- he didn't ask a single question. It was always some comment or suggestion or polite disagreement. I kept wondering who this guy was, who seemed to know just as much or more about every presenter's topic. So I glanced at his name tag and googled him after it was all over: Ben Artin...

Hey, that's funny- his pgp key is right next to meeroh's key on the keyserver. I haven't heard from meeroh in a long time. If you've written more than 3 lines of PowerPlant code, you probably remember meeroh from comp.sys.mac.oop.powerplant. Most of the questions I had over the years were answered by him, sometimes in a previous post, sometimes my own. That dude was smart as hell, wouldn't it be great to meet him...

Oh, look- meeroh changed his name to Ben Artin.

Dammit! That was meeroh! 10 feet away from me all day. No wonder he seemed to know so much. He did.

So, I didn't meet meeroh/Ben. Maybe next time. But I did talk to lots of excellent coders, and had a blast. Quick shouts to Paul Kafasis, John Gruber, Steve Dekorte, DB, Daniel Jalkut, Brent Simmons, and Ed, Mike and Kevin from Apple. Hopefully I'll see all of you again next year...

numMacDevBlogs++;

2006-12-15T20:07:00.000-08:00

Welcome, all, to YAMDB. I write Mac code and I have opinions, so it's only fitting that I should have a blog. Also, Daniel Jalkut told me to start one, and I don't want to disappoint.

I've been writing Mac code for about 8 years, and only recently took the Obj-C/Cocoa plunge. So far, no regrets other than the message dispatch overhead(flame at will). It does seem curious, though, how "Mac development" seems to be synonymous with "Cocoa development" these days. Maybe it's just me, but now that I have a reason to learn Unix, I find the underlying system equally as fascinating as Apple's latest API. Before the flames engulf me- I am not insulting Cocoa, and I am enjoying learning more about Cocoa every day from all the other Mac devs. It's simply easier for me to learn the Unix stuff, with good ole C.

With that in mind, I hope to balance out the Cocoa-heavy blogosphere with a bit of the old-fashioned, procedural Unix goodness. I reserve the right to also post Cocoa stuff occasionally.

I also hope to keep things purely technical and avoid politics. Given the current climate of MacHeist, phantom exploits, and general Wintards, we'll see how that pans out.