Objective-C implicit conversion loses integer precision 'NSUInteger' (aka 'unsigned long') to 'int' warning

Question

I'm working through some exercises and have got a warning that states:

Implicit conversion loses integer precision: 'NSUInteger' (aka 'unsigned long') to 'int'

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
    @autoreleasepool {

        NSArray *myColors;

        int i;
        int count;

        myColors = @[@"Red", @"Green", @"Blue", @"Yellow"];

        count = myColors.count; //  <<< issue warning here

        for (i = 0; i < count; i++)

        NSLog (@"Element %i = %@", i, [myColors objectAtIndex: i]);
    }

    return 0;
}

Screenshot

Martin R · Accepted Answer · 2013-06-04T13:25:40.417

483

The count method of NSArray returns an NSUInteger, and on the 64-bit OS X platform

NSUInteger is defined as unsigned long, and
unsigned long is a 64-bit unsigned integer.
int is a 32-bit integer.

So int is a "smaller" datatype than NSUInteger, therefore the compiler warning.

See also NSUInteger in the "Foundation Data Types Reference":

When building 32-bit applications, NSUInteger is a 32-bit unsigned integer. A 64-bit application treats NSUInteger as a 64-bit unsigned integer.

To fix that compiler warning, you can either declare the local count variable as

NSUInteger count;

or (if you are sure that your array will never contain more than 2^31-1 elements!), add an explicit cast:

int count = (int)[myColors count];

edited Jun 04 '13 at 13:25

answered Jun 04 '13 at 13:19

Martin R

529,903
94
1,240
1,382

20

Just to add - I voted up this answer as I received a crap load of warnings and errors all of a sudden in my Xcode 5 project. You mentioned 64bit which lead me to look at my build settings. Xcode changed it to 64bit mode which threw up errors. Changing it back to arvm7 fixed all of them. – Robert J. Clegg Jan 08 '14 at 07:11
1

@Tander is there a performance difference between compiling 64bit vs armv7? – Shaun Budhram Mar 13 '14 at 19:24
1

@ShaunBudhram By the looks of it nope. I haven't seen any difference. It will only make a difference in apps that use the CPU heavily - games for example would see a benefit compiling for 64 bit. – Robert J. Clegg Mar 13 '14 at 19:27
The update to Xcode 5.1.1 seemed to provoke this problem for me, with the result that I had a shedload of errors when performing assignments like ' int rating = [changedRating integerValue]; ' or using an integerValue with a %i format. – johnlholden May 06 '14 at 10:52
@johnlholden: Yes, because Xcode now compiles iOS applications for 32-bit *and* 64-bit by default. – Martin R May 11 '14 at 14:24
7

"Starting February 1, 2015, new iOS apps uploaded to the App Store **must include 64-bit support**..." - [Apple Developer News and Updates, October 20, 2014](https://developer.apple.com/news/?id=10202014a) – Pang Dec 08 '14 at 03:32
@JayprakashDubey: Can you explain what you mean? I have told in the answer how to fix the warning, is there any problem with it? – Martin R Feb 06 '15 at 11:53
@MartinR : If I do not fix warning will it create any problem such as reject from App Store or misrepresent any values? – Jayprakash Dubey Feb 06 '15 at 12:39
2

@JayprakashDubey: Apple does not see your compiler warnings because you submit the binary compiled application to the App Store. Therefore your app cannot be rejected because of compiler warnings. Of course you should fix them to make your app work correctly. – Martin R Feb 06 '15 at 12:57

score 24 · Answer 2 · answered Jul 30 '14 at 23:16

24

Contrary to Martin's answer, casting to int (or ignoring the warning) isn't always safe even if you know your array doesn't have more than 2^31-1 elements. Not when compiling for 64-bit.

For example:

NSArray *array = @[@"a", @"b", @"c"];

int i = (int) [array indexOfObject:@"d"];
// indexOfObject returned NSNotFound, which is NSIntegerMax, which is LONG_MAX in 64 bit.
// We cast this to int and got -1.
// But -1 != NSNotFound. Trouble ahead!

if (i == NSNotFound) {
    // thought we'd get here, but we don't
    NSLog(@"it's not here");
}
else {
    // this is what actually happens
    NSLog(@"it's here: %d", i);

    // **** crash horribly ****
    NSLog(@"the object is %@", array[i]);
}

answered Jul 30 '14 at 23:16

Adrian

1,066
1
13
20

6

You are right that casting the result of `indexOfObject:` would be a bad idea. My answer was meant for the specific code in the question, and the `count` method cannot return `NSNotFound`. I did not recommend to cast to int or ignore warnings generally. Sorry if that was unclear. In fact your sample code would generate a warning at `if (i == NSNotFound)` if compiled for 64-bit, so the problem would not go unnoticed. – Martin R Aug 04 '14 at 06:53
@Adrian: If you don't mind, what do you suggest the asker do? – May 22 '15 at 03:29
@moonman239 In general, I would use a variable of the correct type if possible (@MartinR's first suggestion) as opposed to casting (his second). As he points out, casting is safe in this particular case, but I think it's a poor habit to get into, as it can have unexpected consequences (as in my example). I posted because I have been bitten by this specific situation (although that's a good point about the == compiler warning, which I must have missed). – Adrian May 24 '15 at 08:07
2

i think count will be used far more often than indexOfObject, and bloating a for-loop with NSInteger just not to have "poor" coding style is nonsense. You should watch solely for indexOfObject and make sure you use NSIntegers there, everything that simply counts something is fine as int, especially within a methods focus – NikkyD Aug 04 '15 at 12:14

Darshit Shah · Answer 3 · 2015-03-18T11:52:07.157

6

Change key in Project > Build Setting "typecheck calls to printf/scanf : NO"

Explanation : [How it works]

Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified, and that the conversions specified in the format string make sense.

Hope it work

Other warning

objective c implicit conversion loses integer precision 'NSUInteger' (aka 'unsigned long') to 'int

Change key "implicit conversion to 32Bits Type > Debug > *64 architecture : No"

[caution: It may void other warning of 64 Bits architecture conversion].

edited Mar 18 '15 at 11:52

answered Jan 21 '15 at 09:48

Darshit Shah

2,366
26
33

if you wanted to just convert your 32 bits library into 64 bits, this is a promising option. – San Mar 28 '15 at 19:26

score 3 · Answer 4 · answered Sep 12 '16 at 11:42

3

Doing the expicit casting to the "int" solves the problem in my case. I had the same issue. So:

int count = (int)[myColors count];

answered Sep 12 '16 at 11:42

Vladimir Despotovic

3,200
2
30
58

or is it called "implicit"? LOL :) In either case, it worked. – Vladimir Despotovic Mar 16 '18 at 11:49

Objective-C implicit conversion loses integer precision 'NSUInteger' (aka 'unsigned long') to 'int' warning

4 Answers4

Linked

Related