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

["Eli Zaretskii" <eliz@elta.co.il>]

> Date: Tue, 20 Jan 2004 00:48:36 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> My point is that we can _change_ the behavior of print.  I think that
> it is reasonable for the process to be something like this:
>   print /format expression
>     Evaluate expression
>     Expression has a type
>      Examine the value of that type according to /format
>       [interpret its bits as a double, or as hex, or whatever...]
> 
> This isn't the first time this has come up, Jim (?) made a similar
> suggestion some time ago for the case of ObjC.  I think that I
> disagreed with it at the time, but I've got a history of being
> inconsistent.
> 
> Think about it.  What use do these have:
>   p/f int_var
>   p/x double_var
> 
> None that I can see.  p (double) int_var is obviously <int_var>.0 in C,
> and p/x (int) double_var is obviously 0x<truncate(double_var)>, but the
> format specifiers don't add value.  Here's some value they could add.
> Now, for ints vs. pointers it may be a little messier.
> 
> This might even let me solve a long-standing complaint.  Given $r1 =
> 0x62636566, I'd love to have a way to make gdb print "bcef".  Or "fceb"
> or whatever else.  p/s $r1?  p/x 0x62636566?  Examine does an implicit
> dereference and print doesn't, so this seems like a logical use of
> printf.

May I wave the truce flag here?

Daniel, do you object to having the feature you wanted in `x', rather
than in `print'?  If you do, could you please explain why?

If having this on `x' is not something we agree to, how about a
`maint' command, or a new format letter for `print' that would
specifically be designed to reveal the bit pattern of the value as it
would be stored in memory?