CC 5.5 vs CC 5.9

Question

I'm trying to port some C++ code from Solaris to Linux. The code was running on Solaris 9, compiled with CC version 5.5. I've installed the Sun StuidoExpress on Redhat EL 4 - which comes with Sun's CC 5.9 compiler (right?). I'm assuming that there is no CC 5.5 for Linux - right? (sorry, I'm a little new to these technologies/tools - I'm even quite rusty with C/C++ - I didn't write the code I'm trying to port).
My problem is that I'm getting "Overloading ambiguity" errors between two operator functions when I compile in Linux. The code compiled fine with CC 5.5 on Solaris. I'm assuming that I'm getting these compiling errors because of the difference between CC 5.5 and CC 5.9 - the later version is better at catching ambiguities. I'm posting because I want to verify this assumption with people who are more familiar with these compilers.
Any comments would be greatly appreciated!

Answer 1

     char operator[] (IC::Uint int i) const;
     char& operator [] (IC::Uint int i);These declarations do not look like valid C++ syntax. Were they copied correctly?
     IC_String pathname;
if(pathname[0] == '/') <-- Error referes to this
Error: Overloading ambiguity between
n "My_String::operator[](unsigned) const" and
"operator[](const char*, int)"You don't show enough code for me to evaluate the error message.
>
The weird thing is that (as far as I understand) the
call looks very ambiguous, but somehow the old
developers got it to compiled using CC 5.5. C++5.5 did not correctly follow the overload resolution rules regarding user-defined and built-in versions of operators like the arrary-index operator []. It is possible that the code is not valid and C++ 5.5 did not catch the error. It is also possible that the code is valid and C++ 5.9 is incorrectly rejecting it.
Are
there compiler flags that would relax a compiler's
check for ambiguous things? No. We have options to relax some rules, but we cannot provide flags to change the way function overload resolution works. (Suppose we had a flag to ignore ambiguity errors. The compiler would pick one function arbitrarily, and you could not predict or control which one.)
To determine whether the problem is in your code or in the compiler, and to suggest how to fix the code, I need to see an example that can be compiled except for the error messages that you cite.