Quote:
Originally Posted by
German1234
Dear All,
I'm porting my scientific program from 32 to 64 bit system
(use gcc, CentOS) and feel myself absolutely confused
after reading general internet advices for that. Could you help me,
please.
The question is:
can I use "old style" on 64 bit:
--------
int * myIntArray;
myIntArray = malloc (sizeof(int)*100000);
for (i=0;i<100000;i++)
myIntArray [i] = i*i;
int j=250;
int b=myIntArray [j];
--------
or should I use a more complicated construction like
--------
for (i=0;i<100000;i++)
myIntArray [(size_t) (i)] = i*i;
int j=250;
int b=myIntArray [(size_t) (j)];
--------
in this simple case throughout the code? Or that all is wrong?
And what should I do with arrays of doubles?
Trivial compilation on 64 bit system of my old code written for 32 bits
gives an executable file which can run, but shows numerical instability, and I'm trying to find the reason...
Thank you very much in advance!
Regards,
German
The 'old' way works fine. There's nothing wrong with integers as array indexes in any architecture C fully supports.
In my experience, a few common things cause problems when porting old code to 64-bit:
- Undeclared functions or missing headers. On 32-bit, printf("hello\n"); will work in 32-bit even if you don't include stdio.h, since there's no effective difference between assuming a function takes an integer and assuming it takes a pointer. In 64-bit, pointers are 64-bit while integers(except long integers) are still 32-bit, resulting in the compiler shoehorning a 64-bit pointer into a assumed-to-be-32-bit integer parameter. Similarly, your example code will crash without stdlib.h since it will assume malloc returns a 32-bit int.
- Mismatched headers. This is what made libfaad2 such a bear to port to 64-bit. It had two separate headers defining the same function in different places, one used internally, one used for external linking. One of them had a long parameter, the other had a uint32. On 32-bit they were effectively the same since int and long are the same size there. On 64-bit, it used 32-bit values internally and was exported as using long values, which had suddenly become 64-bit.
- long values. A lot of code in the last 10 years has been written on the assumption that a long value is 32 bits, the same as an integer. In a 64-bit architecture that's obviously not true.
- Pointer mangling. Like mismatched headers, but done explicitly. This generates lots of 'conversion of pointer to integer' warnings that C programmers quickly become accustomed to ignoring since putting a 32-bit pointer in a 32-bit integer is perfectly safe. In 64-bit, the integer may still be 32-bit but the pointer is definitely not.
So in summary, hunt for longs, don't get lazy about headers, and treat all warnings as errors unless you know for a fact the conversion in question is safe.
Relevant articles