> struct string
> {
>   char* location;
>   int length;
> 
>   operator const char*() const{return location;}
>   /*  operator const char*() {return location;} */
>   operator char*() {return location;}
> };
> 
> main() {
>   int i;
>   string s1;
>   const string s2=s1;
> 
>   i=strlen(s1);
>   i=strlen(s2);
> }

Has anybody had a chance to look at this report? I assume that
strlen in the example is 

int strlen(const char*);

which makes me believe that the following analysis matches the
standard.

In order to call strlen(s2), an implicit convertion from string
to const char* is needed. There are two such sequences:

string -> char* -> const char*
string -> const string -> const char*

According to [over.ics.user], both are userdefined conversion
sequences. Therefore, ranking is based on [over.ics.rank]/3, last
bullet. There it says

>> User­defined conversion sequence U1 is a better conversion sequence
>> than another user­defined conversion sequence U2 if they contain
>> the same user­defined conversion function or constructor and if the
>> second standard conversion sequence of U1 is better than the second
>> standard conversion sequence of U2.

Since these two sequences do not contain the same user-defined
conversion function, there is not a single one that is better than the
other. Therefore, this conversion is an ambiguous one as defined in
[over.best.ics]/10. Since the function selected from the candidate
list is one that requires the conversion, the above program is
ill-formed. So egcs is right to produce diagnostics.

What puzzles me is that the addition of the third operation silences
g++. This give the additional conversion

string -> const char*

which has an identity conversion as second standard
conversion. However, it still uses a different user-defined function
than any of the other two sequences, and therefore does not rank
better than any of these.

So I believe that egcs should still produce diagnostics, and the
program should be changed to use explicit conversions.

Regards,
Martin