Problems occured during migration from 32bit to 64bit

[BALAJI CHANDRAN]

Dear sir,



Problems occured during ompiling for 64 bit using +DD64 +M2 option

Problem 1:

I am using va_arg function in my C file.I am getting the warning like this


int ip= va_arg(ap, int);

long ip= va_arg(ap, long);


cc: "check.c", line 361: warning 530: LP64 migration: Casting from loose
to strict alignment: Resulting pointer may be misaligned.
cc: "check.c", line 361: warning 530: LP64 migration: Casting from loose
to strict alignment: Resulting pointer may be misaligned.
cc: "check.c", line 361: warning 530: LP64 migration: Casting from loose
to strict alignment: Resulting pointer may be misaligned.



Problem 2:

In our application we have to pass the return value of time function ie long value as the parameter to the alarm ()function,but alarm function takes the unsigned int only...


How to avoid both of this problem?


Regards
Balaji

[Michael Tully]

Hi,

I can't help you with the second problem, but this posting could assist with the first.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xd5547bb04b5cd611abdb0090277a778c,00.html

HTH
Michael

[rick jones]

Most systems these days "require" (without really slowing-down the code) variables to be aligned on byte boundraries matching their length.

For example, an int is four bytes long, and it generally need to be aligned on a four-byte boundary.

"32-bit" mode on PA-RISC/IPF/etc is also called "ILP32" which stands for Ints Longs and Pointers are 32-bit - aka four bytes.

64-bit mode is LP64 - Longs and pointers are 64 bit - aka eight byte. So, a long needs to be in memory on an 8 byte boundary.

So, if you take something that is a pointer to an int, that pointer will only be four byte aligned. However, a pointer to a long needs to be 8 byte aligned. Sometimes something that is four-byte aligned is also 8 byte aligned, sometimes not. If you try to access a long from a four-byte boundary, the application will abort. Hence the warning.

Basically, the compiler is warning you that your 64-bit transtion isn't complete. Either the int needs to become a long, or the long an int.

Now, for problem two, why do you want to to pass the number of seconds since the epoch to the alarm function?!?

In a 64-bit compile time() returns a 64-bit quantity for seconds since the epoch. This is to fix the "2038" problem when the 32-bit unsigned integer holding seconds since the epoch would roll-over.

[Dennis Handly]

>warning 530: LP64 migration: Casting from loose to strict alignment: Resulting pointer may be misaligned.

This should be finally fixed by the addition of some extra casts in <varargs.h>.