Converting 32-bit Application Into 64-bit Application in C

Question

I am presently working on converting a 32-bit application into a 64-bit application in C. This application is currently working on x86 architecture (Windows, osx, Unix, Linux). So, before starting coding, I wanted to know what do I need to consider while converting the application.

Answer 1

1. Find out who wrote it. Are they an idiot? Are they you from a few years ago? Can you ask them questions? Are they familiar with the existence of multiple platforms and systems? Knowing the mind-set of the author(s) of the program will help you understand problems when you run into them.
2. Get a 64-bit machine/build environment up and running.
3. Replace long with int. Be perfectly aware that LONG is not long.
4. Replace (int)&x casts and typing with intptr_t and (unsigned int)&x with uintptr_t
5. Audit anything that relies on casting structures to char* to do pointer arithmetic with it.
6. Regex search for \<4\> in case you assumed 4 = sizeof(void*)
7. Be patient. When you find a problem, look elsewhere if the same problem exists, and wrap the solution in a macro.
8. Try not to use #ifdef RUN64 or anything similar. You'll regret it if 128-bit platforms ever go into vogue.
9. Encapsulate all of your changes in terms of some centralized macros that'll hide the portability differences elsewhere in your program.
10. Use a coverage tester to help make sure you've covered everything (if appropriate)

EDIT added uintptr_t note as suggested by comment.

Answer 2

One potential problem not already mentioned is that if your app reads or writes binary data from disk (e.g., read an array of structs using fread), you are going to have to check very carefully and perhaps wind up having two readers: one for legacy files and one for 64-bit files. Or, if you are careful to use types like uint32_t and so on from the <stdint.h> header file, you can redefine your structs to be bit-for-bit compatible. In any case, binary I/O is a thing to watch out for.

Answer 3

This really depends on the application and how it has been coded. Some code can just be recompiled with a 64-bit compiler and it will just work, but usually this only happens if the code has been designed with portability in mind.

If the code has a lot of assumptions about the size of native types and pointers, if it has a lot of bit packing hacks or of it talks to an external process using a byte specified protocol but using some assumptions about the size of native types then it may require some, or a lot, of work to get a clean compile.

Pretty much every cast and compiler warning is a red flag that needs checking out. If the code wasn't "warning clean" to start with then that is also a sign that a lot of work may be required.