Your use of NSInteger is probably the right choice, but causes some problems with STAssertEquals.
STAssertEquals fails if two objects have different types of Objective-C
Lone 1
will be interpreted by the C compiler as (signed int), which has an encoding of type "i".
These macros will also fail:
unsigned u = 1; STAssertEquals(u, 1, nil); // Fails because u is type "I" (unsigned int) and 1 is type "i" (int) char c = 1; STAssertEquals(c, 1, nil); // Fails because c is type "c" (signed char) and 1 is type "i" (signed int)
To make the compiler a different type for 1
, you must add a suffix, such as 1U
for (unsigned int), 1UL
for (unsigned long) or 1L
for (long).
NSInteger is defined as the same size as pointers, which depends on the architecture of the device. On 32-bit Mac OS X and iOS, NSInteger is either type (signed int) or "i". On 64-bit Mac OS X, this is a long, or "q" type. (64-bit Mac OS X is an LP64 architecture, which means that L ongs and P are both types: 64- bit)
So the left side of your STAssertEquals is "q", while the right side is "i", causing a type mismatch.
Your decision to use (NSInteger) 1
seems to accurately reflect what you want - test the NSInteger variable with an NSInteger constant of value 1.
source share