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);
Related
I am new to iOS, I just tried to build my Unity game for iOS and it gives me these errors. See image. Can someone help? Please
Typedef redefinition with different types ('NSUInteger' (aka 'unsigned long') vs 'enum MTLPixelFormat')
Redefinition of enumerator 'MTLPixelFormatBGRA8Unorm'
Redefinition of enumerator 'MTLPixelFormatBGRA8Unorm_sRGB'
This error is raised as your project is using Metal.framework and iOS simulator does not support metalframework. If you run your project on iphone device it will run fine.
To fix this problem simply comment out the offending lines.
//typedef NSUInteger MTLPixelFormat;
//enum
//{
// MTLPixelFormatBGRA8Unorm,
// MTLPixelFormatBGRA8Unorm_sRGB,
//};
(Source)
I'm creating an adobe air extension for iOS, and have a newbie question :)
I get an error
....cpp:27:28: Cast from pointer to smaller type 'uint32_t' (aka 'unsigned int') loses information
in these lines:
FREObject ptr;
FRENewObjectFromUint32((uint32_t)shape, &ptr);
:(
FlashRuntimeExtensions.h I've copied from AirSDK18, and I thought it is compatible with iOS 64 bit?..
*Question is simple, but google didnt helped me.
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;
I am using zxing and OpenCV lib in my project. I updated my XCode from 4.5 to 4.6 today and I am getting this error.
externalLibs/boost/include/boost/gil/channel_algorithm.hpp:54:85: Non-type template argument evaluates to -1, which cannot be narrowed to type 'unsigned long long'
And this error is on this line of code in one of the class of OpenCV Library:-
struct unsigned_integral_max_value : public mpl::
integral_c< UnsignedIntegralChannel,-1> {};
On Earlier version of Xcode its working fine.
Thanks in advance.
It seems boost doesn't like c++ 11 support added with the new clang compiler
so.. it say disable c++ 11 support in build settings
= src: see https://svn.boost.org/trac/boost/ticket/7270
The max value of an unsigned long long variable is in hex 0xFFFFFFFF FFFFFFFF, i.e. all bits are 1's. If interpreted as a signed number, this corresponds to a -1. So often programmers use -1 instead, hoping that the compiler will not complain. Apparently, this did not happen in XCode 4.5, but 4.6 does more rigorous checking...
I'm running into the same error when compiling on macOS Sierra with Apple LLVM version 8.1.0 (clang-802.0.42) and -std=c++11. To solve the problem I included the following compiler flag: -Wno-error=c++11-narrowing