I have implemented sqlCipher in my IOS Project and when I run it shows 25 warnings like 'implicit conversion loses integer precision 'size_t' (aka 'long') to 'int''.So Please suggest How to get rid of these warnings. Any help will be appreciated.
Change datatypes from int to long and your warning will be not shown anymore.
for example below statement giving that warning mentioned in question,
int i = [self someMethod]; //this method's return type is NSInteger
So it will give this warning so change it like,
long i = [self someMethod];
Related
I'm getting this warning "#warning 64BIT: Check formatting arguments" when upgrading my iOS app to the 64-bit architecture using Apple's 64-Bit conversion script.
Here's the code:
NSString *string;
NSInteger min=1;
string=[NSString stringWithFormat:#"%ld minutes",(long)min];
min was an int, which I changed to NSInteger. I also then changed the format statement from %i to %ld and type casted min to long.
Warning appears right above the string= line. This warning is showing up everywhere I changed an int to an NSInteger.
IIRC, the 64-bit conversion process adds this wherever it detects a format string being used. There should be an actual line in the code that begins with #warning. The warning is simply put there to alert you to double-check to make sure your formatting arguments are correct; once you've done this, you should be able to delete the #warning line from your source code and the warning should go away.
Recently I turned on CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION in Xcode and I am overwhelmed with nullability related warnings in my Objective-C code. The one warning type that is most prevalent is Implicit conversion from nullable pointer 'TypeA * _Nullable' to non-nullable pointer type 'TypeA * _Nonnull'.
I started my attempt to remove with these warnings by creating a local of the same type in a method as described here.
https://www.mail-archive.com/xcode-users%40lists.apple.com/msg02260.html
This article says by first using a local, that object is of attribute unspecified nullable, so it can be used as legit parameter to the methods expecting nonnull.
But I feel this is a cop out move and really not solving the issue in any beneficial way.
Has anyone gone through this exercise already? I would be grateful if you can share a strategy that you took.
Actually, I have messed around with that topic for a little bit. I wanted to improve nullability situation in a somewhat big project (make it more 'swiftier'). Here is what I found.
Firstly, you should turn on CLANG_WARN_NULLABLE_TO_NONNULL_CONVERSION (-Wnullable-to-nonnull-conversion)
Secondly, about
first using a local, that object is of attribute unspecified nullable,
so it can be used as legit parameter to the methods expecting nonnull.
This smells bad, and I created a macro called NONNUL_CAST(). Here is example how to implement it:
#define NONNUL_CAST(__var) ({ NSCAssert(__var, #"Variable is nil");\
(__typeof(*(__var))* _Nonnull)__var; })
Here you can see hacky __typeof(*(__var))* _Nonnull)__var, but it is not so bad. If __var is of type A* _Nullable we dereference __var, so it's type now just A, after we make reference again, but _Nonnull, and get nonnull __var as answer. Of course we assert to, in case something goes wrong.
Thirdly, you must specify nullabilty on every local variable, and you should put all your code in NS_ASSUME_NONNULL_BEGIN/END, like this:
NS_ASSUME_NONNULL_BEGIN
<your_code_goes_here>
NS_ASSUME_NONNULL_END`
You put there EVERY LINE (except imports) of your code, in .h and .m files. That will assume that all your arguments of methods, return types and properties are nonnull. If you want to make it nullable, put nullable there.
So, all done, now what?
Here is example of typical usage:
- (Atype*)makeAtypeWithBtype:(nullable BType*)btype {
Atype* _Nullable a = [btype makeAtype];
if (a) {
// All good here.
return NONNUL_CAST(a);
} else {
// a appeared as nil. Some fallback is needed.
[self reportError];
return [AtypeFactory makeDeafult];
}
}
Now you have more robust nullability situation. May be it is not looking nicely, but it is objective-c, so nothing to complain about.
Not every warning makes sense. Sometimes it's a shortcoming in the compiler. For instance, this code doesn't need a warning.
- (nullable id)transformedValue:(nullable id)value {
id result = value != nil ? UIImageJPEGRepresentation(value, 1.0) : nil;
return result;
}
We are checking to see if it's null! What more can we do? Why create an extra pointer?
So, we do this:
- (nullable id)transformedValue:(nullable id)value {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wnullable-to-nonnull-conversion"
id result = value != nil ? UIImageJPEGRepresentation(value, 1.0) : nil;
#pragma clang diagnostic pop
return result;
}
Why is this the proper answer?
First, it's OK to be smarter than the compiler. You don't want to start trashing your code, just because of a bogus warning.
This solution specifies the exact warning message to suppress, and it suppresses it for just one line.
I've opened an old game project in Xcode 6.1.1 (made with Xcode 5.x) started it in the simulator with the iPad Air simulator and discovered after compiling it lots of strange warnings in the SoundOAL.m in many lines of this file. They mostly say something like this:
"Incompatible pointer types passing 'NSUInteger *' (aka 'unsigned long *') to parameter of type 'ALuint *' (aka 'unsigned int *')"
I think I know what it means (ps: app works without problems), but I was wondering if anything has changed and needs to be changed by me. I tried to find something in the iOS 8 docs but I could not read anything. Maybe someone knows it better?
They're warnings due to their now being 64 bit support. You can ignore them, but if you see any unexpected results you should look there.
Since iOS devices support 64-bit, NSUInteger is 64-bit. Your code is passing a pointer to an NSUInteger to a method that takes an ALuint, which is defined in al.h as being 32-bit:
/** unsigned 32-bit integer */
typedef unsigned int ALuint;
To remove the compiler warnings, change your NSUInteger variable types to ALuint or cast them where appropriate, eg:
alSourceStop((ALuint)sourceID);
I just upgraded Xcode + iOS SDK to the latest versions (5.1/7.1) and am now getting a bunch of errors about implicit conversions losing precision (NSInteger to int etc).
Does anybody know if there is a compiler flag or something that allows me to tell the compiler to treat those as warnings rather than errors again? I couldn't find anything so far. I really don't want to go through the code and add explicit casts everywhere as this would be in a lot of places.
This is an error for good reason. NSInteger throughout your codebase will make sure that when you compile the code for 32 and 64 bit iOS devices they are handled consistently. In the 32 bit world NSInteger and int were the same, but with the advent of the iPhone 5S and the iPad Air, iOS is no longer 32 bit only.
As others have said, there really is no way around this if you don't want trouble with modern devices.
If you just want to get back to work and deal with this problem later, then you need to remove arm64 from the 'Valid Architectures' and 'Architectures' items in your project's Build Settings.
As others have said, you really should fix the warnings, but this was a nasty little surprise by Apple (that is, adding the arm64 architecture to Build Settings on Xcode 5.1) so I can totally understand wanting to put these warnings away for a while and work on what ever you were working on before you decided to upgrade.
Indeed XCode now includes the arm64 architecture.
NSInteger is something completely different now as it is define in NSObjCRuntime.h :
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif
To deal with it you should improve your codebase. First of all, you have to be really consistent. Assign NSInteger only to NSInteger and not to int. Avoid all kind of :
int i = [aString integerValue] ( as it returns a NSInteger)
but
NSInteger i = [aString integerValue] (and if it's a long type then you won't have any trouble.)
Moreover, another issue you might have is when you want to create a string from a value.
What you could do is something like:
#define cL(v) (long)(v)
#define cUL(v) (unsigned long)(v)
NSLog(#"array.count: %ld", cUL(anArray.count));
array.count returns an unsigned int under armv7(s) and an unsigned long under arm64. By always casting into an unsigned long you will not face any warning anymore and, more important, do not get any bug.
This "logic" have been introduced by Apple itself on some tech-talks videos there:
https://developer.apple.com/tech-talks/videos/ (video "Architecting Modern iOS Games". Play the video around 10m00s)
You should go and cast them the way they ought to be. Apple isn't complaining for no reason - it also ensures that you don't get any weird unexpected behaviour later down the line. I suggest you go and cast them all. It's extreme but well, it's clean.
I am converting my iOS app to 64-bit. I have the latest Xcode 5.1 (beta 4) installed.
When I compiled the app, I received over 100 warnings and most of them are pretty easy to fix. However, I have a warning on the following code:
+ (CommentResponseStatus)commentReponseStatusCodeWithStatusString:(NSString *)_status
{
NSArray *commentStatusString = [NSArray arrayWithObjects:#"success", #"needConfirmation", #"stopped", nil];
return [commentStatusString indexOfObject:_status];
}
Where CommentResponseStatus is declared as:
typedef enum {
success,
needConfirmation,
stopped
} CommentResponseStatus;
I have a warning "Implicit conversion loses integer precision: 'NSUInteger' (aka 'unsigned long') to 'CommentResponseStatus'"
The warning is on the line return [commentStatusString indexOfObject:_status];
In NSArray we have - (NSUInteger)indexOfObject:(id)anObject;
I am confused about this warning and don't know for now how to fix it. Any quick help would be appreciated.
According to apple docs about 64-bit changes.
Enumerations Are Also Typed : In the LLVM compiler, enumerated types can
define the size of the enumeration. This means that some enumerated
types may also have a size that is larger than you expect. The
solution, as in all the other cases, is to make no assumptions about a
data type’s size. Instead, assign any enumerated values to a variable
with the proper data type
To solve this, create enumeration with type as below syntax.
typedef NS_ENUM(NSUInteger, CommentResponseStatus) {
success,
needConfirmation,
stopped
};
or
typedef enum CommentResponseStatus : NSUInteger {
success,
needConfirmation,
stopped
} CommentResponseStatus;