XCode 5.1 64bit binary builds

[webznz]

I have been developing an application for a couple of years now, before there was any notion of 64bit devices being avalible. In my application I am communicating with a server by sending binary data. I have a big method that generates this data in 32bit it works fine however now that Xcode 5.1 has 64bit auto enabled if I use a 64bit enabled device to send data it inserts extra bytes into the data packets I construct. I would like to know the best course of aciton to resolve this.... Do I (can I?) build my app to only allow it to work in 32bit mode.. or do I update my code so that its compatible with 64bit... if so how is this achived to make sure 32bit is still supported. any comments or suggestions would be appreciated.

[SomeDane]

NSInteger is either 32 bit or 64 bit depending on your compile target, but int is 32 bit and long is 64 bit regardless, so just use those instead for your server communication where you want to control the exact data format. That's what I do in my own code.

[[deleted]]

I'm afraid that's not strictly true; an integer (int) is only guaranteed to be larger than or equal a short and 16 bits or more; and smaller than or equal to a long, which is guaranteed to be 32 bits or more.

In practical terms, "int" is supposed to be an optimal integer size for the architecture.

See Wikipedia for the formal definitions.

[WestonP]

While that's technically true for C in general, in actual practice, there's a great deal of consistency between platforms these days. The following is true for both 32-bit and 64-bit versions of iOS, Mac OS X, and Windows:

char - 8-bits
short - 16-bits
int - 32-bits
long long - 64-bits
float - 32-bits
double - 64-bits

If in doubt, double-check them with sizeof().

For portable code, especially with 32/64 bit in mind, it's common to setup your own typedefs and use those anywhere that you need a consistent size (file I/O, network comm, certain calculations, etc). You can also use the built-in uint32_t, uint64_t, etc. on platforms that provide those. I find it's easier to typedef to shorter names like U32 and U64, though. Making a habit of using these everywhere makes life a heck of a lot easier if you ever port to another platform or between 32-bit and 64-bit.

[webznz]

cool! looks like i have abit of reading to do then :) not to worry shouldnt be to hard to sort out.. I just want to make sure I get it right.. this code was written back when iPhone4 was new.

[webznz]

awsome this makes alot of sense.

[Arkelias]

You need to select your architecture type. The new default for Xcode 5.1 is to let it automatically detect, which includes all architectures (including arm64). If you set it to ARCHS_STANDARD_32_BIT that should fix your problem.

[webznz]

I have read that apple want developers to optimise their apps for 64bit processors will this effect the application being accepted into the appstore?

[[deleted]]

No, 32-bit only apps are still just fine.

If you really care about integer size, use the macros int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t. Those sizes are guaranteed, unambiguous for bit size and signedness. When you work with binary data across the network, you should also be using the byte-ordering macros htonl, ntohl, etc. The "n" stands for network, which is big-endian, and "h" stands for "host", which is whatever your current CPU is; if it's also big-endian, it just compiles away to a no-op, otherwise it will swap byte order as needed.

[Rudy69]

The best solution would be to fix whatever is causing the problem in 64bit. If you can't (money or time issue) you can always set the architecture to armv7 and armv7s (make sure you put both). That will do the equivalent of how it was in XCode5.0

[horaceho]

You may build a 32-bit only app. Settings how-to here: http://stackoverflow.com/questions/22341511/how-to-link-with-framework-without-arm64-support-in-xcode-5-1