Re: [patch] fix for c++/2416

[Aleksandar Ristovski <aristovski@qnx.com>]

Daniel Jacobowitz wrote:
> 
> For expressions, casting one reference to another is OK; casting a
> reference to a non-reference is also fine.  Only non-reference to
> reference is trouble.
> 
>>> The new error is incorrect, which does suggest some missing tests.
>>> You can cast from a reference type; value_cast follows references,
>>> so an int is just like an int &.
>>>
>>> Like Michael, I don't understand the value.c changes.  Could you
>>> explain them?
>>>
>> I replied to that.
> 
> What about the changes to coerce_array?
> 

I haven't made any changes to coerce_array itself, only made sure we do not call 
it if it's not an array. But I find its implementation somewhat confusing: it 
looks like it can be called with all kinds of TYPE_CODE for the arg... if that 
is correct than the name is misfortunate... and if not, then we should determine 
why is it being called with TYPE_CODE_REF (my patch eliminates one place where 
this is being done).

Another thing that confuses me is such a special treatment for references to 
something... in my mind, (talking about C++) we should be able to internally 
treat them as pointers to that something. For example, in the fix I provided if 
you comment out

   //if (TYPE_CODE (value_type (val)) == TYPE_CODE_ARRAY)

in value.c:1042 (after applying my patch) it will call, as without the patch, 
coerce_array; then if you follow to coerce_ref you will see that after 
coerce_ref, address is messed up causing printing garbage (no surprise since the 
address is wrong).


Unfortunately I do not have time at the moment to get any deeper than this, but 
I will reiterate (and please feel free to enlighten me with the reasons) that I 
do not see reasons for treating TYPE_CODE_REF in a different way than TYPE_CODE_PTR.