64bit porting issues on sparc solaris using C++ 5.8 compiler

[shobhah]

Hi,

We have a complete succsssfully working product on 32bit sparc solaris machine for which compiler used is CC 5.8
Now we are migarting our product from 32 bit to 64bit sparc solaris machine.
While porting we need 64 bit compiler issues for our application product which is wriiten in completely C++.
We tried with -xarch=v9 and -xport64=full compiler options to find out 64bit porting problems. But we did not find any issues for our product.

Please let us know any technique to get these porting issues while migrating from 32bit to 64bit.

Thanks

[sicarie]

Hi,

We have a complete succsssfully working product on 32bit sparc solaris machine for which compiler used is CC 5.8
Now we are migarting our product from 32 bit to 64bit sparc solaris machine.
While porting we need 64 bit compiler issues for our application product which is wriiten in completely C++.
We tried with -xarch=v9 and -xport64=full compiler options to find out 64bit porting problems. But we did not find any issues for our product.

Please let us know any technique to get these porting issues while migrating from 32bit to 64bit.

Thanks

Did you get an error message? Are you recompiling the source on a 64 bit machine?

[AdrianH]

Hi,

We have a complete succsssfully working product on 32bit sparc solaris machine for which compiler used is CC 5.8
Now we are migarting our product from 32 bit to 64bit sparc solaris machine.
While porting we need 64 bit compiler issues for our application product which is wriiten in completely C++.
We tried with -xarch=v9 and -xport64=full compiler options to find out 64bit porting problems. But we did not find any issues for our product.

Please let us know any technique to get these porting issues while migrating from 32bit to 64bit.

Thanks

The only possible porting problems I could see might be in persistant storage. Even then I don't think that would be the case, unless the endianess has changed and you are storing information in a binary format. But that is not a 32-64bit port issue, that is an endian issue.

I think that C/C++ have come a long way in porting issues. They usually don't change the interface in such a way that makes it break older software, unless it is deemed unsafe. (though the char * a="hi"; one still bugs me allowing someone to do a[1]='o'; later on which won't be caught until runtime)

So maybe there are no issues like you said.


Adrian

[shobhah]

Did you get an error message? Are you recompiling the source on a 64 bit machine?

Hello,

Thanks for your quick response.
We are recompiling the source on 32bit machine with options -xarch=v9 and -xport64=full to get porting warnings. We are not getting any error messages , The source files are compiled perfectly without any issues. Even the 64bit COFF format object files(*.o) files are created perfectly.
So we are not understanding whether there are any porting issues in our code or not.
Can we use FlexLint software to find out porting issues now at this situation?
Please tells us how to proceed now.

Thanks
Shobha

[shobhah]

The only possible porting problems I could see might be in persistant storage. Even then I don't think that would be the case, unless the endianess has changed and you are storing information in a binary format. But that is not a 32-64bit port issue, that is an endian issue.

I think that C/C++ have come a long way in porting issues. They usually don't change the interface in such a way that makes it break older software, unless it is deemed unsafe. (though the char * a="hi"; one still bugs me allowing someone to do a[1]='o'; later on which won't be caught until runtime)

So maybe there are no issues like you said.


Adrian

Thanks or quick response.
Do you think there are no porting issues in our C++ code?
Can we move further thinking that there are no porting issues?

Thanks
Shobha

[AdrianH]

Thanks or quick response.
Do you think there are no porting issues in our C++ code?
Can we move further thinking that there are no porting issues?

Thanks
Shobha

Sorry for the late reply. I've been away.

If there are no porting warnings, I would assume that means there is nothing in your code that would present a problem. That said, have you tried to run the app? Does it work?

One potential issue would be if you assigned a size_t to an int or used a int in place of a size_t. If size_t was given a type of unsigned long long (64bit number) then:

• The former example would probably give you a warning saying that you are truncating the value.
• The latter example would go on without issue, but you will not be able to use a library to its fullest as you will be passing a subset of the potential numbers that it could be passed.

Hope this helps.


Adrian