I have faced with following issues during the migration of an application from Unix (Solaris - 32 bit OS) to RHEL 5 (64 bit OS). I will be very much thankful to whom who can give some idea on it.
(1) One of the code uses #pragma ident, #ident and #pragma map, which is ignored when compiled in Linux. Will it affect in the functioning / performance of the application.
(2) Is there any problem - during 32 bit to 64 bit conversion, in using function pointers (doubly linked list) as an element in structures.
(3) What are the major issues to be considered while doing this type of migration

Thank You

1. It would be an unusual app that would be affected by those. Portable apps normally would not be. But you may face the issue if the app was written for Solaris and you are now porting it to Linux/GNU.

2. Function pointers, like other pointers, will be larger. Structs having pointers should not normally be used for writing external data. But some programmers are know do such a dumb thing, so if the data goes external and comes back, written by the 32 bit version and read by by the 64 bit version, you'll have much trouble. But that trouble can sometimes exist even with different C compilers for the same pointer size.

3. At the programming level, be sure your code is written in the properly semi-abstract portable manner (reference symbols that describe the architecture instead of hard coding numbers. A few constants like 0xffffffff might need to be rewritten ... (~0) would be a better way that adapts to the integer size.

1 members found this post helpful.

I'd like to add to what Skaparen wrote that you should pay particular attention to code that uses int variables to temporarily hold the value of a pointer. That is surprisingly common, and will fail when you move from 32-bit to 64-bit architectures.

One should use intptr_t from stdint.h instead of int to store a pointer in an integer variable. If that is not possible, then one can, in practice, use long. (Code that uses long to store pointers works fine in Linux, because all 32-bit architectures are ILP32 and 64-bit LP64; thus long and pointer always the same size.)

I would just avoid using an integer to hold a pointer where possible. But legacy code often has these issues, often from the days when people thought 640K is all the memory anyone would ever need.

No need to insult! We are, after all, talking about Unix systems, not some dumpster-diven mockery of an operating system.

The typical use is actually the opposite -- using a void pointer to hold an integer value -- but the same rules apply: don't use int, use intptr_t if possible (and long otherwise). A lot of interfaces use a void pointer to hold any type of user data; the pthread thread functions are a good example.

I was racking my brain to think of any good examples where one might need to hold a pointer in an integer variable (instead of the opposite), but I could not think of any. I don't think I've ever needed to do so myself. (Pointer differences I often store in integer variables; in general, one should use ptrdiff_t, but if you know the order of the pointers, then size_t is safe, too. That is not the same thing, however.)

So, I do agree: don't use an integer to hold a pointer. But, like I said, one may have to use a (void) pointer to hold an integer; and then, the integer should be of intptr_t or long type.

also pay attention to compiler warnings. For example fumction returning pointer with no declaration works on 32 bit world (because int is the default return value). On 64 bit world returned address may be truncated.

And ints were typically used to hold pointer values when some pointer arithmetic was involved.

Just try it; if your program compiles and works without problems, then everything is okay; otherwise try one or more of these:

* switch to 32 bit mode: -m32 flag at compilation and linking
* examine compiler warnings (if any; use flags -W -Wall -pedantic)
* use debugger (if there are runtime errors)
* use efence (or similar product) if suspect invalid memory usage
* examine the whole code carefully (takes lot of time)

Hi Skaperen,

Thank You for attending my query.

As you said that there may arise problems when migrating from Solaris to Linux in para 1, the same happened to me. Can you distinguish anyone (like pragma etc)?

And about function pointers, these are used to create/generate some messaging structures for data interchange. Initially it was designed in 32 bit Solaris and now migrating to RHEL5 (64 bit), and this is also a constraint to me which is not able to create the structure properly.

The best idea would be actually trying to compile and run the program.

nevem is correct. Try it out. Also running program with valgrind might ve a good idea - although if program has some strict timing criterias you may not be able to use valgrind which typically significantly slows down execution.

i m agree with Maz_