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

前端 未结 9 1071
悲&欢浪女
悲&欢浪女 2020-12-04 17:02

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

相关标签:
9条回答
  • 2020-12-04 17:35

    The two major differences between 32-bit and 64-bit programming in C are sizeof(void*) and sizeof(long). The major problem that you will have is that the most Unix systems use the I32LP64 standard which defines a long as 64 bits and Win64 uses the IL32LLP64 standard which defines a long as 32 bits. If you need to support cross-platform compilation, you may want to use a set of architecture based typedefs for 32-bit and 64-bit integers to ensure that all code will behave consistently. This is provided as part of stdint.h as part of the C99 standard. If you are not using a C99 compiler, you may need to roll your own equivalent

    As noted elsewhere the primary concerns for conversion will be code that assume sizeof(int) == sizeof(long) == sizeof(void*), code to support data that has been written to disk and code for cross platform IPC.

    For a good review of the history behind this, take a look at this article from ACM Queue.

    0 讨论(0)
  • 2020-12-04 17:37

    The main problem you face when switching to 64 bit is that the size of pointers are different (64 bit instead of 32 - duh) The size of integers and the size of longs might differ too, depending on platform.

    Why is this a problem? Well, it's not, unless your code assumes that sizeof(int) == sizeof(void*). This could lead to nasty pointer bugs.

    0 讨论(0)
  • 2020-12-04 17:44

    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.

    0 讨论(0)
提交回复
热议问题