General
cancel
Showing results for 
Search instead for 
Did you mean: 

Migrating source code from 32 to 64 bits

SOLVED
Go to solution
Chanquete
Occasional Advisor

Migrating source code from 32 to 64 bits

Hi people!
I'm compiling an app. from Pa-RISC 32 bits to Itanium 64 bits. I compile it fine (cc +DD64), linking with 64 bits libraries (i also use oracle libraries). I solved the warning messages that i didn't see when i compile under 32 bits.
I think all is OK. But the same program show different results that under 32 bits.
My questions are: Are there any kind of differences in source code (ANSI C) from 32 to 64 bits? Are the variable length equals?
Is the first time i have to program under 64 bits, i don't know if i have to learn something different or not!!
Thanks!!
14 REPLIES
Steven Schweda
Honored Contributor
Solution

Re: Migrating source code from 32 to 64 bits

> Are the variable length equals?

Pointers aren't. If you have doubts, write a
small test program, build it (both ways), and
run the resulting executables. For example:

alp $ type siz.c
#include

main()
{
printf( " char = %d, int = %d, long = %d, long long = %d, void* = %d.\n",
sizeof( char), sizeof( int), sizeof( long),
sizeof( long long), sizeof( void *));
}


> But the same program show different results
> that under 32 bits.

Choose one problem and debug it. I would
expect you to learn more from that experience
than you will from any guesses I could make
without being able to see any of your code.
Chanquete
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

Hi Steven!
I have been reading info about 64 bits programming. I see the differences about 'long' and 'pointers' length. By the moment i will steel working under 32 bits, because i'm also migrating from PA-RISC to Itanium. When my programs works fine in Itanium (under 32 bits), i will study more about 64 bits programming and the changes i have to do in my source code. It are requeriments of my boss.
Surely i'll ask here another questions in a future.
Thanks so much!!
Gweeper64
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

Have you tried compiling your code in 32 bit mode on the Itanium (leave off the +DD64) to see if it is really a 64 bit issue vs some other platform difference?

Gweeper64
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

oops.... never mind. I see you are trying that.
Dennis Handly
Acclaimed Contributor

Re: Migrating source code from 32 to 64 bits

>PA-RISC 32 bits to Integrity 64 bits.

There is no requirement to go to 64 bit. You should ask your boss why he thinks 64 bit is needed??

>Is the first time I have to program under 64 bits, I don't know if I have to learn something different or not!!

You have to port to 64 bit, i.e to do work and know what you are doing.
There are a +wlint +w64bit options to help you.

Have you seen the documentation under:
http://www.hp.com/go/cpp

HP-UX 64-bit porting and transition guide
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801/?ciid=2308852bcbe02110852bcbe02110275d6e10RCRD

>Steven: build it (both ways) printf(" char = %d, ... sizeof(char),

This already violates 64 bit porting. The correct format on HP-UX is: %ld
Even more pedantically: %lu
Or C99 perfection on 11.31: %z
Steven Schweda
Honored Contributor

Re: Migrating source code from 32 to 64 bits

> This already violates 64 bit porting.

How? "sizeof" isn't an int? "%d" doesn't
work with an int?

Please point me to the docs which explain
this.
Chanquete
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

Hi people!
I don't know why my boss (above the customer) loves 64 bits... I don't mind it, i only have to do what they order me!
I'm seeing that i'll have problems in the treatment of 'long' and pointers. When i know something more about the world where i'm entering, i'll start to ask you over and over.
Thanks so much!!
Dennis Handly
Acclaimed Contributor

Re: Migrating source code from 32 to 64 bits

>Steven: "sizeof" isn't an int?

No, sizeof is a size_t. On HP-UX that's a unsigned long.

>Please point me to the docs which explain this.

The C or C++ Standards?
http://docs.hp.com/en/B3901-90020/ch05s13.html

>I don't know why my boss (above the customer) loves 64 bits

It should be clear in his mind, at least enough to explain to you. Some valid reasons are:
1) Wants to port to Linux on Integrity.
2) Needs more address space because it is close to the 2 Gb limit.
3) Third party shlibs only come in 64 bit.
Chanquete
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

Hi people!
I have a doubt with my code.
I have a 'long field' variable, and on another side i get, via Oracle SQLDA structures, data from my DB. Look at this line:
--- field = *(long *)std_outp->V[0];
Really, it's a conversion from 'char **' to 'long'. It works perfectly under 32 bits. An example of my values at this point:
>>>>>>> std_outp->V[0] = '989999'
>>>>>>> field = 989999
But, compiled under 64 bits, it gives me:
>>>>>>> std_outp->V[0] = '989999'
>>>>>>> field = 4252013328072704
To do fine the 'cast', i have to type:
--- field = *(int *)std_outp->V[0];
I know the problem is in the length of pointers and 'long' under 64 bits. But i find this conversion, via 'int', something 'horrible', i think that there has to be another way more 'beautiful' to do the cast. Are there?
Thanks in advance!
Dennis Handly
Acclaimed Contributor

Re: Migrating source code from 32 to 64 bits

>I have a 'long field' variable, and on another side i get, via Oracle SQLDA structures, data from my DB. Look at this line:

This is not a long in your database. This is an int32_t. You should get used to using explicit sizes in your port, especially if you have existing data files.

>field = *(long*)std_outp->V[0];
>it's a conversion from 'char**' to 'long'.

Why do you think this is a char**? Is V a char***?

>compiled under 64 bits, it gives me:
> std_outp->V[0] = '989999'
> field = 4252013328072704

You should debug this by printing both in hex.

>I find this conversion, via 'int', something 'horrible', I think that there has to be another way more 'beautiful' to do the cast.

Cast to int32_t*.
Chanquete
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

Hi!
Sorry, but i was a bit lost. Re-reading my question i realize than i was explaining so horrible. I was mixing concepts.
Well, SQLDA->V is a char**:
struct SQLDA {
/* ub4 */ int N;
/* text** */ char **V;
/* ub4* */ int *L;
/* sb2* */ short *T;
/* sb2** */ short **I;
/* sb4 */ int F;
/* text** */ char **S;
/* ub2* */ short *M;
/* ub2* */ short *C;
/* text** */ char **X;
/* ub2* */ short *Y;
/* ub2* */ short *Z;
};

In an Oracle's example, it uses also this cast (to convert to '%d' value to printf):
*(int *)select_dp->V[i]
when the field has a NUMBER value.

If Oracle does it, i'll do it.

Thanks a lot!
Dennis Handly
Acclaimed Contributor

Re: Migrating source code from 32 to 64 bits

>SQLDA->V is a char**:

So V[0] is a char* and you were converting a char* to a long*, then dereferencing it.
Chanquete
Occasional Advisor

Re: Migrating source code from 32 to 64 bits

Oh, sorry, Dennis. You're so right!
But i have important news: my customer hear my words (i'm influential...) and we discard at the moment migrate the application to 64-bit.
And now we have a trouble:
Anybody knows something about the future of 32-bit in HP-UX? If the HP's future plan is not include 32-bit compatibility, we can think about 64-bit porting.
Thanks a lot, people!
Dennis Handly
Acclaimed Contributor

Re: Migrating source code from 32 to 64 bits

>Anybody knows something about the future of 32-bit in HP-UX? If the HP's future plan is not include 32-bit compatibility

There are no current plans to change this.
Perhaps when there are 128 bit computers. :-)