[patch] fix for c++/2416

Daniel Jacobowitz drow@false.org
Wed Feb 27 23:50:00 GMT 2008


On Wed, Feb 27, 2008 at 04:08:08PM -0500, Aleksandar Ristovski wrote:
> 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).

This arises from the C language standard coercions, more or less.
It is supposed to be called with references, functions, pointers, et
cetera.  If you give it an array, it gives you back a pointer to the
first element; the same if you do it with a reference to an array.

> 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.

No, we try to treat them as the thing referenced-to, not the pointer
doing the referencing.  This is to be consistent with the languages
we're evaluating.  Expression evaluation and printing goes wrong if
you don't.

> 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).

value_as_address on a reference is supposed to referenced value as an
address, not the pointer value stored in the reference.  It's probably
the caller of value_as_address which is mistaken.

-- 
Daniel Jacobowitz
CodeSourcery



More information about the Gdb-patches mailing list