LOG_EXPR(x) is a macro that prints out x, no matter what type x is, without having to worry about format-strings (and related crashes from eg. printing a C-string the same way as an NSString). It works on Mac OS X and iOS. Here are some examples,

LOG_EXPR(self.window.screen);

self.window.screen = <UIScreen: 0x6d20780; bounds = {{0, 0}, {320, 480}}; mode = <UIScreenMode: 0x6d20c50; size = 320.000000 x 480.000000>>

LOG_EXPR(self.tabBarController.viewControllers);

self.tabBarController.viewControllers = (
“<UINavigationController: 0xcd02e00>”,
“<SavingsViewController: 0xcd05c40>”,
“<SettingsViewController: 0xcd05e90>”
)

Pretty straightforward, really. The biggest convenience so far is having the expression printed out, so you don’t have to write out a name redundantly in the format string (eg. NSLog(@"actionURL = %@", actionURL)). But LOG_EXPR really shows it’s worth when you start using scalar or struct expressions:

LOG_EXPR(self.window.windowLevel);

self.window.windowLevel = 0.000000

LOG_EXPR(self.window.frame.size);

self.window.frame.size = {320, 480}

Yes, there are expressions that won’t work, but they’re pretty rare for me. I use LOG_EXPR every day. Several times. It’s not quite as good as having a REPL for Cocoa, but it’s handy.

Give it a try.

How It Works

The problem is how to pick a function or format string to print x, based on the type of x. C++’s type-based dispatch would be a good fit here, but it’s verbose (a full function-definition per type) and I wanted to use pure Objective-C if possible. Fortunately, Objective-C has an @encode() compiler directive that returns a string describing any type it’s given. Unfortunately it works on types, not variables, but with C99 the typeof() compiler directive lets us get the type of any variable, which we can pass to @encode(). The final bit of compiler magic is using stringification (#) to print out the literal string inside LOG_EXPR()‘s parenthesis.

The Macro, Line By Line

1 #define LOG_EXPR(_X_) do{\
2 	__typeof__(_X_) _Y_ = (_X_);\
3 	const char * _TYPE_CODE_ = @encode(__typeof__(_X_));\
4 	NSString *_STR_ = VTPG_DDToStringFromTypeAndValue(_TYPE_CODE_, &_Y_);\
5 	if(_STR_)\
6 		NSLog(@"%s = %@", #_X_, _STR_);\
7 	else\
8 		NSLog(@"Unknown _TYPE_CODE_: %s for expression %s in function %s, file %s, line %d", _TYPE_CODE_, #_X_, __func__, __FILE__, __LINE__);\
9 }while(0)

1. The first and last lines are a way to put {}‘s around the macro to prevent unintended effects. The do{}while(0); “loop” does nothing else.
2. First evaluate the expression, _X_, given to LOG_EXPR once, and store the result in a _Y_. We need to use typeof() (which had to be written __typeof__() to appease some versions of GCC) to figure out the type of _Y_.
3. _TYPE_CODE_ is c-string that describes the type of the expression we want to print out.
4. Now we have enough information to call a function, VTPG_DDToStringFromTypeAndValue() to convert the expression’s value to a string. We pass it the _TYPE_CODE_ string, and the address of _Y_, which is a pointer, and has a known size. We can’t pass _Y_ directly, because depending on what _X_ is, it will have different types and could be of any size.
5. VTPG_DDToStringFromTypeAndValue() returns nil if it can’t figure out how to convert a value to a string.
6. Everything went well, print the stringified expression, #_X_, and the string representing it’s value, _STR_.
7. otherwise…
8. The expression had a type we can’t handle, print out a verbose diagnostic message.
9. See line 1.

The VTPG_DDToStringFromTypeAndValue() Function

See the source in VTPG_Common.m:

It’s derived from Dave Dribin‘s function DDToStringFromTypeAndValue(), and is pretty straightforward: strcmp() the type-string, and if it matches a known type call a function, or use +[NSString stringWithFormat]:, to turn the value into a string.

The First Step Twords Fixing Your Macro Problem is Admitting it…

So yeah, maybe I went a little wild with macros here…

But it took out some WET-ness of the original code, and prevents me from accidentally mixing up types in a long wall of ifs, eg.

else if (strcmp(typeCode, @encode(NSRect)) == 0)
{
    return NSStringFromRect(*(NSRange *)value);
}
else if (strcmp(typeCode, @encode(NSRange)) == 0)
{
    return NSStringFromRect(*(NSRange *)value);
}

If I were cool, I’d use NSDictionarys to map from the @encode-string to an appropriate format string or function pointer. This is conceptually cleaner; less error-prone than using macros; and almost certainly faster. Unfortunately, it gets a little tricky with functions, since I need to deference value into the proper type.

One final note from my testing, I could do away with the strcmp()s, because directly comparing @encode string pointers (eg if(typeCode == @encode(NSString*)) works. I don’t know if it will always work though, so relying on it strikes me as a profoundly Bad Idea. But maybe that bad idea will give someone a good idea.

Limitations

Arrays

C arrays generally muck things up. Casting to a pointer works around this:

char x[14] = "Hello, world!";
//LOG_EXPR(x); //error: invalid initializer
LOG_EXPR((char*)x); //prints fine

__func__

Because it is a static const char [], __func__ (and __FUNCTION__ or __PRETTY_FUNCTION__) need casting to char* to work with LOG_EXPR. Because logging out a function/method call is something I do frequently, I use the macro:

#define LOG_FUNCTION()	NSLog(@"%s", __func__)

long double (Leopard and older)

On older systems, LOG_EXPR won’t work with a long double value, because @encode(long double) gives the same result as @encode(double). This is a known issue with the runtime. The top-level LOG_EXPR macro could detect a long double with if((sizeof(_X_) == sizeof(long double)) && (_TYPE_CODE_ == @encode(double))). But I doubt this will ever be necessary.

I haven’t actually written any code that uses long double, because I use NSDecimal, or another base-10 number format, for situations that require more precision than a double.

Scaling and Frameworks

Growing LOG_EXPR to handle every type is a lot of work. I’ve only added types that I’ve actually needed to print. This has kept the code manageable, and seems to be working so far.

The biggest problem I have is how to deal with types that are in frameworks that not every project includes. Projects that use CoreLocation.framework need to be able to use LOG_EXPR to print out CoreLocation specific structs, like CLLocationCoordinate2D. But projects that don’t use CoreLocation.framework don’t have a definition of the CLLocationCoordinate2D type, so code to convert it to a string won’t compile. There are two ways I’ve tried to solve the problem

Comment-out framework-specific code

This is pretty self-explanatory, I’ll fork VTPG_Common.m and un-comment-out code for types that my project needs to print. It works, but it’s drudgery. Programmers hate that.

Hardcode type info

The idea is to hard-code the string that @encode(SomeType) would evaluate to, and then (since we know how SomeType is laid out in memory) use casting and pointer-arithmetic to get at the fields.

For example:

//This is a hack to print out CLLocationCoordinate2D, without needing to #import <CoreLocation/CoreLocation.h>
//A CLLocationCoordinate2D is a struct made up of 2 doubles.
//We detect it by hard-coding the result of @encode(CLLocationCoordinate2D).
//We get at the fields by treating it like an array of doubles, which it is identical to in memory.
if(strcmp(typeCode, "{?=dd}")==0)//@encode(CLLocationCoordinate2D)
	return [NSString stringWithFormat:@"{latitude=%g,longitude=%g}",((double*)value)[0],((double*)value)[1]];

This Just Works in a project that includes CoreLocation, and doesn’t mess up projects that don’t. Unfortunately it’s horribly brittle. Any Xcode or system update could break it. It’s not a tenable fix.

Areas for Improvement

If there’s some type LOG_EXPR can’t handle that you need, please jump right in and improve it!

When I have time, I plan to write a general parser for @encode()-strings. This will let me print out any struct, which mostly solves the type-defined-in-missing-framework problem, and would let LOG_EXPR Just Work with types from all kinds of POSIX/C libraries.

Using LOG_EXPR() in Your Project

Download VTPG_Common.m and VTPG_Common.h from my github repository, and add them to your Xcode project.

Now just add the line #import "VTPG_Common.h" to your prefix file (named <ProjectName>_Prefix.pch by default), after the #ifdef __OBJC__, for example:

#ifdef __OBJC__
    #import <Foundation/Foundation.h>
    // maybe other files, depending on project  template...
    #import "VTPG_Common.h"
#endif

Now LOG_EXPR() will work everywhere in your project.

A Few Sneaky Ideas

It’s not hard to come up with ways to fool App-Store reviewers.

You might just get lucky. With over 230,000 Apps in the store, reviewers are swamped. They’re only human and they might not notice some subtle evil — especially if it’s not on their naughty-behavior list.

Time-Bombs, apps that hide their bad-behavior for a few days, are undetectable without periodic audits, since they act normally during the pre-release review period.

Phoning home to a server that let’s an app know it’s passed review and can begin it’s life of crime, would let an app be even more precise.

With just a few minutes thought, I’m sure you can think of even more clever tricks, or combination of tricks.

Not a Fully Open Vulnerability

That’s not to say your iPhone is in as much danger as your PC. iOS apps don’t have the same free-reign that traditional computer programs have. That limits their usefulness, but it also limits the damage they can cause. An iOS App can’t stop you from killing it, and it can’t mess with other apps, so it can’t “take over” your phone. But it can do anything it likes with your Contacts, and secretly abuse the phone’s always-on network connection, and get up to other sorts of minor mischief.

I don’t have room here to fully analyze the risks of a rogue iPhone’s program. But generally, the danger isn’t too great: a little more than a what website can do, a lot less than what a PC program with administrator access can do.

Ultimately, Apple’s best defense against malware isn’t control of the App Store review process or iTunes payments (although they help), but control over iOS. A well-designed operating system limits what kinds of malware are possible. The review process can screen for egregious mistakes. But it can’t catch everything, and it’s least-able to catch the most clever malware, which ultimately, are the programs we should be most worried about. Apple’s review process doesn’t provide real security against modern malware.

The best source I can recommend for understanding the kinds of designs that take full advantage of high PPI displays are Edward Tufte‘s classic design books:

If you just get one, make it The Visual Display of Quantitative Information.

PS: Tufte’s books are themselves examples of beautiful, complex, high density design, and as such really only make sense printed. At least for the next few years. Even if you can find an electronic version, I wouldn’t recommend reading it, because it won’t convey the power of a 1600 PPI display (printer).

For those of you who aren’t familiar with how building iPhone software works, we developers spend thousands of hours testing and debugging our programs in an iPhone Simulator application that runs on our Macs. The simulator can’t run Apps from the App Store, only programs compiled from source code with Xcode. So the only people using the simulator are programers, or otherwise deeply involved with building iOS apps. Apple could make it so that any iAds in the simulator would show special ads targeted to developers.

Better still, iAds in the simulator could show something useful like rules from the Human Interface Guidelines (that too few read), good tips or even inspiring quotations.

For sample code that gets a directory robustly, using NSSearchPathForDirectoriesInDomains(), see Finding or creating the application support directory.

Because NSHomeDirectory() encourages so many bad practices, it should be deprecated.

Disabling NSHomeDirectory() in Your Projects

Add the following macro to your prefix file:

#define NSHomeDirectory() NSHomeDirectory_IS_DISCOURAGED_USE_NSSearchPathForDirectoriesInDomains_TO_GET_A_SUBDIRECTORY_OF_HOME

Then any use of NSHomeDirectory() will give the compiler error:

Tell Me I’m Wrong

If you’ve seen a legitimate use of NSHomeDirectory() please leave a comment! Just because I can’t think of one doesn’t mean they don’t exist.

…She bent forward to put a white hand on my knee. “There is wealth in that cellar beneath the garage. You may have whatever you ask”.

I shook my head.

“You aren’t a fool!” she protested. “You know-”

Let me straighten this out for you,” I interrupted. “We’ll disregard whatever honesty I happen to have, sense of loyalty to employers, and so on. You might doubt them, so we’ll throw them out. Now I’m a detective because I happen to like the work. It pays me a fair salary, but I could find other jobs that would pay more. Even a hundred dollars more a month would be twelve hundred a year. Say twenty-five or thirty thousand dollars in the years between now and my sixtieth birthday.

“Now I pass up about twenty-five or thirty thousand of honest gain because I like being a detective, like the work. And liking work makes you want to do it as well as you can. Otherwise there’d be no sense to it. That’s the fix I am in. I don’t know anything else, don’t enjoy anything else, don’t want to know or enjoy anything else. You can’t weight that against any sum of money. Money’s good stuff. I haven’t anything against it. But in the past eighteen years I’ve been getting my fun out of chasing crooks and solving riddles. It’s the only kind of sport I know anything about, and I can’t imagine a pleasanter future than twenty-some years more of it. I’m not going to blow that up.

Excerpt from The Gutting of Couffignal by Dashiell Hammett. All monies are in 1927 US Dollars. It’d buy me a couple of nice houses today.

That’s the link to all your facebook-friend’s phone numbers.

Every time I see one of those “I need ya phone numbers” things on facebook I post that link. Please do the same. At least until the phone companies fix the real problem by automatically backing up contacts from the phone “in the cloud

General

These Terms of Service govern your use of the USATODAY.com website (the “Site”) only and do not govern your use of other USA TODAY services, such as services offered by the USA TODAY print newspaper.

Clearly this invalidates the agreement on the iPhone, since the iPhone App is not “the USATODAY.com website”.

This is mildly embarrassing for USA TODAY, and even more of a fumble for Mercury Intermedia, who built the app. But I can’t think of any way this actually hurts anyone, even in theory. Users are already bound by the App Store Terms and Conditions, so why bother putting your own EULA (that nobody’s ever going to read much less care about) in your app?

¹To see the EULA, tap that little i near the bottom left of the homescreen, then tap Terms of Service. The text above was copied from version 1.5 of the USA TODAY iPhone App.

given this function,

void foo(char* s){
	printf("s is at: %p\n s is: '%s'\n", s, s);
}

and that

char s[] = "Joy!";
foo(s);

prints out

s is at: 0xbffff46b
s is: ‘Joy!’

what will this next line print?

foo(&s); //WHAT WILL THIS DO?

Pick all that apply:

1. Print “Joy!”
2. Print garbage
3. Print the same address for s
4. Print the a different address for s
5. Crash
6. Go into an Infinite loop

Answer

Answer: one and three

Yeah, it’s not what I expected either, especially since:

@encode(__typeof__(s)) = [5c]
@encode(__typeof__(&s)) = ^[5c]

In fact, all of these are equvalent (modulo type warnings):

foo(s);
foo(&s[0]);
foo(&(*s));
foo(&s);

Explanation.