NSInteger and NSUInteger in a mixed 64bit / 32bit

Question

I have a fair amount of string format specifiers in NSLog / NSAssert etc. calls which use %d and %u with NSInteger (= int on 32bit) and NSUInteger (= unsigned int on 32bit) types respectively.

When converting the app to 64bit, this gives warnings (of course), as %ld %lu is expected for what now became a long and unsigned long type.

Simply converting the format specifiers will of course introduce the reverse warnings in the 32bit build.
So the only solution I see to become warning free is using the 64bit specifiers, and casting to the 64bit value types everywhere a warning is given in the 32bit build.

But I was wondering if perhaps there are format specifiers specifically for the NSInteger and NSUInteger type which would work on both architectures without casting?

Answer 1

I think the safest way is to box them into NSNumber instances.

NSLog(@"Number is %@", @(number)); // use the highest level of abstraction

This boxing doesn't usually have to create a new object thanks to tagged pointer magic.

If you really don't want to use NSNumber, you can cast primitive types manually, as others suggested:

NSLog(@"Number is %ld", (long)number); // works the same on 32-bit and 64-bit

Answer 2

You can also use %zd (NSInteger) and %tu (NSUInteger) when logging to the console.

NSInteger integer = 1;
NSLog(@"first number: %zd", integer);

NSUInteger uinteger = 1;
NSLog(@"second number: %tu", uinteger);

Also to be found here.

Answer 3

No, (unfortunately) there is no printf format that directly corresponds to NS(U)Integer. So for architecture independent code, you have to convert everything to the "long" variant (as the Xcode "Fix-it" suggests):

NSInteger i = ...;
NSLog(@"%ld", (long)i);

The only alternative that I know of is from Foundation types when compiling for arm64 and 32-bit architecture:

// In the precompiled header file:
#if __LP64__
#define NSI "ld"
#define NSU "lu"
#else
#define NSI "d"
#define NSU "u"
#endif

NSInteger i = ...;
NSLog(@"i=%"NSI, i);

using preprocessor macros (but even the author of that answer calls it a "admittedly awful approach").