This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] fix for c++/2416
- From: Daniel Jacobowitz <drow at false dot org>
- To: Aleksandar Ristovski <aristovski at qnx dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 1 Apr 2008 10:29:48 -0400
- Subject: Re: [patch] fix for c++/2416
- References: <47C5A5EE.6070107@qnx.com> <20080227193546.GA11796@caradoc.them.org> <47C5BE84.7050803@qnx.com> <20080227200019.GB12434@caradoc.them.org> <47C5D138.6020909@qnx.com> <20080227220659.GE14556@caradoc.them.org> <47C70319.4050804@qnx.com> <20080228191516.GA8975@caradoc.them.org> <47C78DD3.4080109@qnx.com>
On Thu, Feb 28, 2008 at 11:45:07PM -0500, Aleksandar Ristovski wrote:
> Allright, then how about this, yet newer and yet more revisited diff? I
> removed changes to eval.c and let it simply call value_cast as it used to.
> Now value_cast knows how to handle references.
We were converging on a fix and then there's a whole different patch
to look at... sorry I couldn't make time until now.
> @@ -257,6 +290,7 @@ value_cast_pointers (struct type *type,
> return arg2;
> }
>
> +
> /* Cast value ARG2 to type TYPE and return as a value.
> More general than a C cast: accepts any two types of the same length,
> and if ARG2 is an lvalue it can be cast into anything at all. */
Please drop the whitespace change.
> @@ -275,6 +309,26 @@ value_cast (struct type *type, struct va
> if (value_type (arg2) == type)
> return arg2;
>
> + code1 = TYPE_CODE (check_typedef (type));
> +
> + /* Check if we are casting struct reference to struct reference. */
> + if (code1 == TYPE_CODE_REF)
> + {
> + /* We dereference type; then we recurse and finally
> + we generate value of the given reference. Nothing wrong with
> + that. */
> + struct type *t1 = check_typedef (type);
> + struct type *dereftype = check_typedef (TYPE_TARGET_TYPE (t1));
> + struct value *val = value_cast (dereftype, arg2);
> + return value_ref (val);
> + }
This allows things like "(int&) int_var", by automatically creating
references. Should we really do that?
--
Daniel Jacobowitz
CodeSourcery