Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Jan 20, 2004 at 09:10:55PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 20 Jan 2004 09:52:25 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > > Daniel, do you object to having the feature you wanted in `x', rather
> > > than in `print'?  If you do, could you please explain why?
> > 
> > Because, at the moment, we have a common syntax shared by print and
> > examine - but some of the options don't make sense (I claim) for print. 
> > But they do all make sense for examine.
> 
> Sorry, I don't see how is this relevant.  Suppose we add a new format
> letter to `x', one that doesn't exist in `print'--would that be okay,
> and if not, why not?
> 
> > I don't think that it is a maintenance command
> 
> We have wuite a few examples of obscure features that we pushed to
> maint.  I don't see why this one cannot.
> 
> I do agree that it's better to have it on a regular command.
> 
> > I also think that adding a new print format flag that examines
> > without changing the existing ones will be more confusing.
> 
> Please tell why.  I don't see why it would be confusing to add a new
> format that is defined to always show the memory representation of the
> value in hex.

I'll respond to these all together, since there's really the same
answer to all of them: I think there is a general unimplemented feature
here, not just the specific "show me the hex representation of this
double".  Examples I have in mind:
  - Displaying an integer to a sequence of characters
      p/s 0x6263 -> "ab"
  - Displaying a double-precision value in hex:
      p/x 2.0 -> 0x4000000000000000
  - Displaying a double-precision value in binary:
      p/t 2.0 -> 01000000000000000000000000000000
                 00000000000000000000000000000000
  - Displaying an integer (hex or otherwise) value as a double
    p/f 0x4000000000000000LL -> 2.0
  - Displaying an integer (hex or otherwise) value as a long
    double - this one is trickier, since we don't normally have an
    integer type that is big enough, but if we did:
    p/gf 0x400000000000000000000000LLL -> 2.0

I didn't pick these examples at random.  I've wanted to do every single
one of these in the past three months, for values in registers rather
than typed-in constants.  I had to store them to the inferior's memory
to do it.  And then x/2x gives you the two words broken up, and you
get:
  0x00000000 0x40000000
when perhaps you wanted:
  0x40000000_00000000
They both indicate that on a little endian system the set bit is in the
most-significant, therefore highest-byte-addressed, byte.

I think that adding a flag to show the representation in hex would be
intuitive, but not general enough, and that extending the existing /x
to do the same thing would be more natural.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer