Points to be considered for writing code which is portable to both 32 and 64 bit architectures

Question

What are the points that should be kept in mind while writing code that should be portable on both 32 bit and 64 bit machines?

Thinking more on this, I feel if you can add your experience interms of issues faced, that would help.

Adding further on this, I once faced a problem due to a missing prototype for a function which was returning returning a pointer. When I ported the same to a 64 bit machine, the code was crashing and I had no clue about the reason for quite some time, later realised that all missing prototypes are assumed to return int causing the problem.

Any such examples can help.

EDIT: Adding to community wiki.

Answer 1

Gotchas:

1. Casting pointers to integer types is dangerous
2. Data structure sizes can change
3. Watch out for sign extension
4. Different ABI?

Some tips & tricks I've found helpful:

1. Get yourself a native-size integer type (from a header or typedef your own) and use it when you have variables that don't care about size.
2. Use explicit variable types wherever possible (u_int64_t, int_32_t, etc.)

Answer 2

• Some integral types may have different sizes
• Pointers are of different lengths
• Structure padding
• Alignment

On Windows, there is only calling convention on x64 as opposed to the multiple on a regular x32 machine.

Things get murkier when you have some components which are 32-bit and some 64-bit. On Windows, I ended up writing a COM service to get them to talk.

Answer 3

Pushing pointers onto the stack takes up twice as much space. Stack size may not change between OS Versions though, causing code that runs fine in 32-bit to mysteriously fail when compiled and run unchanged on 64-bit. Don't ask me how I know this.

Answer 4

Write automated tests and run them regularly on both platforms.

Answer 5

sizeof(int) might != sizeof(void*)

alignment. Its possible that alignments needs might change. This can expose bugs where you have been mistreating things that should have been aligned but were only aligned by accident in 32 bit (or on a processor that doesnt care)

dont pass 0 into varargs if the receiver is expecting a pointer. This is painful in C++ where savvy devs know that 0 is a valid null pointer. A C dev will usually use NULL so you are probably OK