Operating System - Linux
1828019 Members
1970 Online
109973 Solutions
New Discussion

C pointer problem on IA64 but not on pa-risc

 
SOLVED
Go to solution
Michael Resnick
Advisor

C pointer problem on IA64 but not on pa-risc

Hi all,

We're moving an app from a D370 PA-Risc machine running HP-UX 10.20 to an ia64 machine with HP-UX 11iv2. I know the answer to my problem is documented somewhere - I can't find it.

The attached sample program runs fine on the d370 machine. Moving the executable onto the ia64 runs fine. However, when recompiled on the ia64 box, I get a memory dump at the point indicated in the source.

I'm sure it must have something to do with 64bit vs. 32bit, but can't find it. Any help would be greatly appreciated!

(The attached code is actually a striped-down version of a larger program.)

Thanks!

mike
4 REPLIES 4
Don Morris_1
Honored Contributor

Re: C pointer problem on IA64 but not on pa-risc

I don't see any attachment, could you add it so we can take a look? Thanks.
Michael Resnick
Advisor

Re: C pointer problem on IA64 but not on pa-risc

I found a note somewhere that said to include to correct a memory allocation problem with malloc. Sure enough, once that was included, the program started working.
rick jones
Honored Contributor

Re: C pointer problem on IA64 but not on pa-risc

It is good you added that include - particularly since the manpage for malloc suggests that it is supposed to be there in the first place :)

If you are migrating to 64-bit, there are some migration compilation options in the compiler you may want to enable. IIRC it is the +M option, but best double check the cc manpage on that one.

However, unless you are explicitly stating +DD64, the default compilation mode for IA64 remains 64-bit.
there is no rest for the wicked yet the virtuous have no pillows
A. Clay Stephenson
Acclaimed Contributor
Solution

Re: C pointer problem on IA64 but not on pa-risc

I'll go a bit further. Your old code was working by accident. It is state of the art dumb, sloppy, and in bad taste to leave out those silly, useless header files. The reason your old code was working is that all undeclared extern functions (which was your situation w/o the declaration in the header file) are assumed to be of type int. In 10.20, both pointers and int's are 32-bit types but in your newer OS ints remain at 32 bits but pointers are 64-bits so with the extern malloc() undeclared, the compiler assumed that it was an int function and missed half of the pointer bits.

If you had even bothered to run your 10.20 code through lint, it would have told you that a potential problem exists.
If it ain't broke, I can fix that.