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

Question

I am presently working on converting a 32bits application into a 64bits application in C. This application is currently working on x86 architecture (Windows, osx, Unix, Linu

Answer 1

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 2

Well, fundamentally, the number of changes are fairly small, but it'll still be a major task if the application isn't carefully written to be somewhat portable to begin with.

The main difference is that pointers are 64 bit wide, but most other datatypes are unchanged. An int is still 32 bit, and a long is probably also still 32 bit. So if your code casts between ints and pointers, that's going to break. Similarly, any struct or similar which depends on a specific offset to a member may break because other members may now be bigger, and so change the offset.

Of course, your code should never rely on these tricks in the first place, so in an ideal world, this wouldn't be a problem at all, and you could simply recompile and everything would work. But you probably don't live in an ideal world... ;)

Answer 3

All about 64-bit for developers:

Articles about 64-bit Development

Links collection 64-bit Resources

Tool Viva64

Answer 4

There are lots of good answers already.

Consider using Gimpel Lint. It can point out exactly the types of constructs that are problematic. If your experience is like mine, it will also show you lots of bugs in the system unrelated to the 32/64 bit port.

Answer 5

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 6

If you used the correct types for your values - eg. size_t, ptrdiff_t, uintptr_t, the fixed sized int types from stdint.h where appropriate - and did not hardcode value sizes, your code should work out of the box.