This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove deprecated_set_value_type


On Tue, Nov 13, 2007 at 07:23:18PM +0000, Rob Quill wrote:
> Is it a correct solution to add a function something like
> copy_val_except_type, which copies all the fields from a value struct
> except the type? So an new value is created of the right type, then
> cop_val_except_type is called, which would replace the other fields.

Sorry for losing this message.  That may be right, but only for some
of the calls.  The trick is to consider not just what the effect of
the current calls is, but what this means in terms of the abstraction
of a "struct value".  Does it make sense to change the type of a value
without changing anything else about it?  In a few cases yes, but
not usually.

I picked one call to deprecated_set_value_type; the one in
c-valprint.c.

              /* Copy value, change to pointer, so we don't get an
               * error about a non-pointer type in value_rtti_target_type
               */
              struct value *temparg;
              temparg=value_copy(val);
              deprecated_set_value_type (temparg, lookup_pointer_type (TYPE_TARGET_TYPE(type)));
              val=temparg;

There's a better way to do this: value_addr of a reference becomes
a pointer to the same object.  Of course, I see that the body of
value_addr does it the same way as this code, using the
deprecated method.  So this call should use value_addr and the
implementation of value_addr probably needs a new method that
doesn't exist yet.  I suggest "value_copy_and_change_type".

To pick another example, printcmd.c uses it to do unchecked
conversions from integers to bit patterns of floating point numbers -
much to my surprise!  I had no idea this was there until I read the
code.  Assuming we want to keep that behavior, the right way
is not to smash the type of some existing value; instead, use
value_zero (not_lval) to create a new value, and copy the
bit pattern into it.

Does that make sense?

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]