[patch] fix for c++/2416
Aleksandar Ristovski
aristovski@qnx.com
Wed Feb 27 21:26:00 GMT 2008
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.
More information about the Gdb-patches
mailing list