When converting 32-bit to 64-bit code in iOS

No. Maybe it might need to change if any int is used as a pointer. Essentially what really changes when it goes 64-bit is the pointer size you generally do not have to worry about. Worry is needed only when you try to exchange numeric types with pointers.

The big difference between 32-bit and 64-bit architectures is the address space that is much larger in 64-bit architectures.

So the main difference in data types between these architectures is in types that store memory addresses, that is, pointers.

For example, in a 32-bit architecture, sizeof(void*) returns 4 bytes, whereas in a 64-bit architecture the same command returns 8 bytes. This difference is required for all address space to be effectively addressed.

There are other issues like setjmp and longjmp , but these are more associated with the (ISA) instructions.

Finally, you should change from int to long if you are going to use values that int do not hold, otherwise there is no need to worry about this.

% of life% s are only problematic if you perform casts between pointers and integers. Some libraries use this instead of using opaque pointers . In these cases, the library is expected to take the necessary care to maintain consistency when the library is compiled in 64 bits, and the programmer must make use of the library data types, making these changes transparent.

Finally, care must be taken when setting the size of structures containing pointers. For example:

typedef struct {
    int *a;
} myStruct;

If we run the int command on the two architectures, we will get different sizes for the same structure.

Imagine the code:

myStruct p;
fread(&p, 4, 1, file);

I'm using an absurd example but that will serve to explain the point

To avoid this is very simple: just use fread :

myStruct p;
fread(&p, sizeof(p), 1, file);