Lap Cat Software Blog

The release of Leopard has given third-party developers a lot to do: attempting to restore features lost from Tiger, for instance. (By the way, where is the second party, and why am I never invited?) My friend Rainer Brockerhoff has provided a way, or Quay, to display hierarchical popup menus in the Dock again. One of my most missed features in Leopard is using NSLog to spew output exclusively to Xcode’s console log. When you debug or run your app in Xcode on Tiger, you can put NSLog calls everywhere without worrying about polluting console.log. In my opinion, console.log is only for important messages and errors. I frequently ask users to consult it if they’re experiencing a problem with an app. Either that or the Oracle at Delphi.

Leopard dispenses completely with console.log, though there is a “Console Messages” database query in Console. Whereas on Tiger stdout and stderr standardly go to console.log, on Leopard they boldly go to system.log (as well as to the “Console Messages” query). On either version of Mac OS X, Xcode redirects stdout and stderr to its own console log, so they don’t appear in Console at all.

According to the documentation, NSLog sends a message to stderr. This is true for Tiger, and it’s also true for Leopard, but Leopard’s NSLog has the additional behavior of sending a message to system.log regardless of whether stderr is redirected. Thus, when you debug or run your app in Xcode (these may amount to the same thing in Xcode 3), messages from NSLog appear both in Xcode’s console log and in system.log! Curiously, there is no duplication of NSLog messages in system.log when stderr is not redirected.

If you prefer to keep your debug output out of system.log, the workaround for this new NSLog behavior is to abandon NSLog for debugging purposes on Leopard. After much experimentation with asl, I realized that our old faithful printf would work. Since printf writes to stdout, its output is redirected by Xcode. Plus, when you’re debugging your app in Xcode you don’t really need NSLog to tell you the name of your app, the date, or your shoe size.

A limitation of printf is that it doesn’t handle the format specifier %@ for an Objective-C object. With Cocoa, therefore, we want an Objective-C wrapper around printf (like, um, NSLog). If you add the following code to your target’s .pch file, you’ll have an Objective-C debug logging function JJLog available throughout your target’s code. To enable logging in your app’s debug build, just add JJLOGGING to the GCC_PREPROCESSOR_DEFINITIONS setting (AKA “Preprocessor Macros”) in the debug build configuration.

#ifdef __OBJC__
	#import <Cocoa/Cocoa.h>
	#ifdef JJLOGGING
		#define JJLog(...) (void)printf("%s:%i %s: %s\n", __FILE__, __LINE__, __PRETTY_FUNCTION__, [[NSString stringWithFormat:__VA_ARGS__] UTF8String])
	#else
		#define JJLog(...)
	#endif
#endif

In your app’s release build, the debug function is a NOP that the compiler will almost certainly optimize out. This conditional code should not cause problems when using GCC_PRECOMPILE_PREFIX_HEADER, because Xcode already generates a separate precompiled prefix header for each build configuration. See the .pch.gch.hash-criteria files in /Library/Caches/com.apple.Xcode.###/SharedPrecompiledHeaders.

You can send gobs of gab to JJLog without repercussion or remorse. However, you’ll still want to use NSLog (sparingly, please) for runtime errors in your release build. Now to continue in the spirit of this post, I’ll redirect the epilogue to /dev/null.

Some people are apparently under the impression that firewall rules are the be-all and end-all of Mac OS X security. Deny all from any to me in. Before you spend days composing the perfect ipfw ruleset, however, take a look at sysctl. (You could spend days looking at sysctl.) One of the biggest misconceptions about Mac OS X — a misconception encouraged by the System Preferences UI — is that the firewall is not enabled out of the box. Nonsense!

net.inet.ip.fw.enable: 1

Admittedly, it’s a fairly flammable firewall (allow ip from any to any), but it’s enabled. More important, the default sysctl settings do provide at least a modest level of protection. For example:

net.inet.icmp.timestamp: 0
net.inet.icmp.maskrepl: 0

These prevent your machine from responding to ping -M time and ping -M mask requests. What time is it? Where the party at?

By Mac OS X herein I shall mean Leopard and Tiger. (Panther is not yet abandonware, but at this point it merely receives Christmas cards.) When you ’start’ the firewall in System Preferences, Tiger adds a number of rules to ipfw. Leopard, on the other hand, includes a new Apple-designed firewall that mostly replaces ipfw. Though Leopard respects custom ipfw rulesets, it adds no rules to ipfw when you choose to block incoming connections. I don’t know much about how the Leopard firewall works; presumably it protects you somehow or other.

Leopard does still employ ipfw for “Stealth Mode”. If you turn that on, both Leopard and Tiger add the rule deny icmp from any to me in icmptypes 8. Curiously, Stealth mode prevents you from ‘pinging yourself’ in Leopard but not in Tiger. For fun (according to a rather loose definition of fun), try ping localhost. Somebody bring me a mirror! The difference in behavior is due to the Tiger-only rule allow ip from any to any via lo* that precedes all other rules.

Looking at the ipfw rules, you might think that Stealth Mode is overrated, like Notre Dame football and most wines over three dollars. If you want to learn its true value, you need to consult sysctl.

net.inet.tcp.blackhole: 2
net.inet.udp.blackhole: 1

With these settings, your computer mercilessly crushes attackers into singularities, as well as dropping their packets without response when sent to closed ports.

It would be nice if Bonjour wasn’t so talkative, broadcasting its greetings to your entire LAN. Bonjour also complains loudly when told to shut up by the firewall. On the other hand, you’re going to have to broadcast anyway for DHCP. Moreover, your LAN will see your internet traffic, especially on wireless.

Whoa, I suddenly realized after all these years that if you’re a grown man who lives in an attic, hangs out with high school students, has an ‘office’ in the bathroom, and is known for one syllable utterances, you’re not cool. You’re a loser.

The Hollywood writers strike continues, and the desperation grows for alternative sources of entertainment. Fortunately, we programmers can find entertainment in our own sources. I’ve got some reality programming for you! The following snippet of code is taken from an actual CVS commit. (Yes, CVS. Don’t laugh. Do cry for me, Argentina.) This build warning ‘fix’ was made by some contractor for some project that I worked on at some point in time for some company. To protect the innocent and/or guilty, I won’t say who, what, when, or where. As for why, I wish I knew. Or maybe not.

NSEnumerator* fileEnum = [fileArray objectEnumerator];
NSDictionary* aDict = nil;
//Changed to Remove the Build Warnings
//while(aDict = [fileEnum nextObject])
while(aDict == [fileEnum nextObject])

Let this example serve as a lesson. Not for programmers — the one who wrote it is probably hopeless — but rather for managers. Please do not just hire the lowest bidder!

Although I abhor self-promotion — much as Roger Federer abhors winning tournaments — someone must take on this thankless task. (I had to fire my publicist, because he had never heard of me.) Thus it is with great regret and sorrow that I announce my latest contribution to the WordPress open source project. It was just one minuscule twitch for mankind, yet one ginormous vault for a man, viz., yours truly.

Now some critics might claim that the security issue was trivial. In my defense, I would argue that critics are doo-doo heads. Except the ones in New York: they all love me.

Although it seems late in the game to be adding new features to Tiger, Mac OS X 10.4.11 includes not only the high-profile Safari 3 update but also a few other interesting little additions. For instance, when you uncompress a .tar.gz file in Finder it no longer leaves behind a useless .tar that you have to manually trash. Neat!

Of course, it wouldn’t be Finder without some annoyance. The trade-off for un-cluttering your Desktop is up-cluttering your console.log:

BOMArchiveHelper[454] opened /Users/jeff/Desktop/.BAHEm7Xn/my-directory.tar

I’m not sure why they didn’t use tar xzf, which is approximately a billion times faster. Baby steps…

It should come as no surprise that Vienna 2.2.1 was released on Sunday. I’ve been too busy the last two days chipping my car out of the ice to write a post here. Release notes are available for the lazy, though real coders read the commit logs.

Contrary to expectations, this is not really a Leopard compatibility release. I would say that Vienna is not yet Leopard ready. On the other hand, I would also say that Leopard is not yet itself ready. So there you have it.

It seems dead, though the clock is still ticking. (Countdown to extinction?) Anyway, I’ve just updated my own extensive list of cocoa blogs and other favorite feeds, which you can download from the Downloads section of my sidebar. FileMerge will reveal the changes in my all-important favor. Remember bloggers, X-Mas is coming soon, not to mention Y-Mas and Z-Mas. I’m keeping track of who’s naughty and nice — mostly by intercepting your wireless packets. If you’re nice, you’ll get a hot dog and a shake.

I bear a heavy burden now, for with the ongoing Hollywood writers strike I am the lone remaining source of pablum in the world. Actually, I was on strike too, from the bagel shop. You know I can’t blog without bagels! However, the recent reconciliation of DLR and EVH inspired us to put aside our differences, and I thought the offer of SCO stock options and tickets to a Broadway show was more than fair. Thus, there will be a series finale to Working without a nib. Maybe they’ll even name a space shuttle after my cat.

Speaking of cats — as I am prone to do — there is a new cat on the Mac (though none on the mat). Apple finally released Mac OS X 10.5, code named “Leopard”, followed soon thereafter by Mac OS X 10.5.1, code named “Oops”. These updates to Mac OS X pose a problem for the Nibless project, because the crucial method +[NSObject poseAsClass:] has been deprecated in Leopard. In fact, this method does not work at all in the Leopard 64-bit runtime.

Fortunately, the new Leopard Objective-C runtime provides a nice solution to the problem. In earlier versions of Nibless we used poseAsClass: to override +[NSBundle loadNibNamed:owner:] while still allowing the original method to be called. We can accomplish the same thing in Leopard via a technique that computer scientists have termed the old switcheroo:

Class bundleClass = [NSBundle class];
Method originalMethod = class_getClassMethod(bundleClass, @selector(loadNibNamed:owner:));
Method categoryMethod = class_getClassMethod(bundleClass, @selector(JJ_loadNibNamed:owner:));
method_exchangeImplementations(originalMethod, categoryMethod);

These functions are documented in the Objective-C 2.0 Runtime Reference. It is straightforward to exchange the method implementations; the mind-bending trick is to call the original implementation afterward.

+(BOOL) JJ_loadNibNamed:(NSString *)aNibName owner:(id)owner
{
	BOOL didLoadNib = YES;
	if (aNibName != nil || owner != NSApp)
	{
		didLoadNib = [self JJ_loadNibNamed:aNibName owner:owner];
	}
	return didLoadNib;
}

Before the function method_exchangeImplementations() is called, the method JJ_loadNibNamed:owner: has the implementation defined above, but the method never gets called until that implementation has been given to the method loadNibNamed:owner:, at which point the method JJ_loadNibNamed:owner: has the original implementation of loadNibNamed:owner:, whatever that may be (only Apple and Uri Geller know for sure). We never get caught in an infinite loop, unlike poor Alice and Norman.

The Leopard version of Nibless you’ve long been waiting for — since the second paragraph — is ready for download. If you find it useful, then please send me a bagel. I’ll also accept a doughnut, but not a Danish. Spoon!

According to Google, CHUD stands for Cinematic Happenings Under Development. However, those of us in the know realize that it stands for Cats Hold Ultimate Domination. Anyway, if you’ve installed CHUD 4.5 you may be wondering why the >bleep< your Processor pane disappeared from System Preferences.

Never fear, it’s not gone entirely. In CHUD 4.4, it was located in /System/Library/PreferencePanes/. In CHUD 4.5, it has been moved to /Developer/Extras/PreferencePanes/. You can find it there and double-click.

Perhaps the move was part of the reorganization of the developer tools for Leopard. Or perhaps they’re just messing with us. See the release notes for … nothing.

While we’re all aiting-way or-fay eopard-Lay, I’d like to share a pointer that I picked up while mugging a C library. (I have no idea what that means. It seemed witty when I wrote it.) As you know, I’m always ahead of the curve, setting the trends, framing the public discourse. Thus, I should add my 1.2 cents — the dollar is weak, and I’m a little short this month — on a hot topic discussed on the Cocoa-dev mailing list recently (in geological time, anyway): the use of the Objective-C BOOL type.

If you look in the header file /usr/include/objc/objc.h, you can see how BOOL is defined:

	typedef signed char		BOOL;
	// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C"
	// even if -funsigned-char is used.

	#define YES             (BOOL)1
	#define NO              (BOOL)0

A char type — e.g., char, signed char, unsigned char — is always one byte, i.e., sizeof(signed char) == 1, whereas in most implementations an int type is more than one byte. A byte standardly consists of 8 bits, or 12 nibbles. What happens to the extra bits if you convert an int into a BOOL? According to the wacky rules of C type conversion, the result is implementation-dependent. Many implementations simply throw away the highest bits. (Other implementations recycle them into information superhighway speed bumps.) As a consequence, it’s possible that myIntVar != 0 && (BOOL)myIntVar == NO.

Usually we don’t have to worry about this, because ‘boolean’ operators in C, such as == and !, always return 1 or 0. When we use bitwise operators, on the other hand, the problem does come into play. Suppose, for example, that we’re testing whether the option key is down. The method -[NSEvent modifierFlags] returns a bit field indicating the modifier keys that are pressed, and bit masks can be used to test for specific keys. Consider the following code; there are situations where doSomethingAfterEvent: does something, yet doSomethingElseAfterEvent: does nothing.

	-(void) doSomethingAfterEvent:(NSEvent *)anEvent
	{
		if (anEvent)
		{
			if ([anEvent modifierFlags] & NSAlternateKeyMask)
			{
				[self doSomething];
			}
		}
	}

	-(void) doSomethingElseAfterEvent:(NSEvent *)anEvent
	{
		if (anEvent)
		{
			BOOL shouldDoSomethingElse = [anEvent modifierFlags] & NSAlternateKeyMask;
			if (shouldDoSomethingElse)
			{
				[self doSomethingElse];
			}
		}
	}

It has been suggested on the mailing list that the type conversion could be handled by

	BOOL shouldDoSomethingElse = !!([anEvent modifierFlags] & NSAlternateKeyMask);

or

	BOOL shouldDoSomethingElse = ([anEvent modifierFlags] & NSAlternateKeyMask) != 0;

However, these approaches would only work for single-bit masks. What if we wanted to test both the option key and the shift key?

The point I wish to make here actually has little to do with the BOOL type. (Say what?!?) Bitwise operators are not boolean operators. A boolean operator only returns 1 or 0. A bitwise operator, in contrast, can return any bit field. The proper way to handle a bitmask is to test whether the resulting bit field has the desired value:

	unsigned int myMask = NSAlternateKeyMask | NSShiftKeyMask;
	BOOL isMyKeyComboPressed = ([anEvent modifierFlags] & myMask) == myMask;

Yes, I know Robot Chicken already covered this subject a ha-while ago. I didn’t really care for it.