On 02/23/10 18:54, Tom Tromey wrote:
>>>>>> "Jan" == Jan Kratochvil<jan.kratochvil@redhat.com>  writes:
>>>>>>              
>
> Finally catching up on this thread...
>
> Jan>  I would prefer the value_print_options way but rather:
>    

Okay, folks, I dusted this off and spun another simple patch using 
value_print_options.  Given an enum:

    enum tt {
       T0,
       T1,
       T2
    };

    enum tt tf = T1;

If you do

    p /f tf

you'll get

    $1 = T1 = (enum tt)1

of instead of the

    $2 = T1

you'd get without the /f flag.  (It's "/f" because 'f' isn't otherwise 
used for enums--'f' for "fancy" or something like that.)

It also doesn't differentiate between printing single enums and enums in 
more complex things like arrays.  Given

    enum tt ta[] = { T1, T0, T2 };

The result would be:

    p /f ta
    $3 = {T1 = (enum tt)1, T0 = (enum tt)0, T2 = (enum tt)2}

As an alternative, maybe it could print something like

    $2 = (enum tt)1 <T1>

which kind looks like the result of printing a character.

As you can see in the attached check summary diff, this patch doesn't do 
a thing to MI or anything else.

If people like this, great.  Otherwise, I'll leave it dead and buried.

> Yes, I think value_print_options is preferable to checking
> ui_out_is_mi_like_p.  My reason is that getting the ui-out object
> involves looking at some global state, whereas value_print_options is
> local to the call hierarchy.  This means that it is simpler to reason
> about and modify.
>
> Tom
>