topic Re: C pointer problem on IA64 but not on pa-risc in Operating System - Linux

C pointer problem on IA64 but not on pa-risc

Michael Resnick — Fri, 23 Sep 2005 22:33:33 GMT

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

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

Don Morris_1 — Sat, 24 Sep 2005 08:14:11 GMT

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

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

Michael Resnick — Sat, 24 Sep 2005 12:16:44 GMT

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.

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

rick jones — Mon, 26 Sep 2005 11:48:51 GMT

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.

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

A. Clay Stephenson — Mon, 26 Sep 2005 12:35:21 GMT

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.