Forte 6.2 c++ compiler on sparc

Question

If I am in the wrong forum, I apologize.
Would appreciate if anyone could direct me to the
right one.
We have an old C++ (more C than C++) shared lib. which
was compiled in Jan. 2002. No one knows what compiler
was used. It was working fine with occasional nasty
crashes. No core created (coresize is not set to zero).
I found that char * datatype encapsulated in a user class
had incorrect reference counting, and often malloc'd
memory was being 'delete'ed instead of free'ing and new'd
memory was being free'd, no checks for nullness of a ptr.
I replaced some of the char * with the STL's string class
and removed, as much as I could, all such inconsistencies.
I compiled it on a forte 6.2 on a Sparc m/c and installed it
on a few Sparc (Sun-Fire-xxxx) and two Ultra-80s.
While I am not sure if the original crash was fixed, the
exes. on the ultra-80 crashed a few times. Cores were
created (an improvement :). If I read the cores into a
debugger, pretty much all stack traces have
std::bad_cast::what() exceptions and in addition two of
the cores also have ostrstream::overflow().
The big questions are :
- Should I compile the lib. using -xarch=ultra-80 for
the ultras ?
- Should I have the compiler upgraded, as I read some
place on Sun site that forte6.2 had casting problems ?
- Should I go back into the code and start looking
for casting problems and other overflow problems ?
And then install some exception handlers.
But the problem with implementing exception handling
is, I will have to have a try and catch block in a lot of
places. At the end of the day, I cannot be sure I have
covered all bases.
Any help, ideas would be deeply appreciated.

Answer 1

Binaries (.o files, libraries, and executables) that use the std::string classs compiled with FD6u2 might not work with updated binaries. Whether they work depends on details of every CC command line used in building the old binaries, and whether libCstd.a was linked instead of /usr/lib/libCstd.so. An incorrect mix of binaries will result in program crashes.
If your programs are working well enough, leave them alone. Otherwise, recompile all C++ code with Sun Studio 11. (There is no good reason to use anything older than Studio 11, and many reasons why you should not.)
The -xarch=v9 option specifies 64-bit code. The default is 32-bit code. You can't mix 64-bit code and 32-bit code in the same program. If the original code was not built using -xarch=v9, do not use it now.
You should specify the -xarch=v8plus option on all command lines for 32-bit code on all Ultrasparc processors. (Pre-Ultrasparc processors have not been used in systems since about 1994.)