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: [PATCH v5] Exit code of exited inferiors in -list-thread-groups


On 06/02/2014 07:30 PM, Simon Marchi wrote:
> On 14-05-21 02:09 PM, Pedro Alves wrote:
>> On 05/21/2014 06:34 PM, Simon Marchi wrote:
>>> On Fri 16 May 2014 04:30:45 PM EDT, Tom Tromey wrote:
>>>>>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:
>>>>
>>>> Simon> This one was also from a year ago, I would like to make sure it is still
>>>> Simon> OK.
>>>>
>>>> Simon> +      if (inferior->has_exit_code)
>>>> Simon> +	ui_out_field_string (uiout, "exit-code",
>>>> Simon> +			     int_string (inferior->exit_code, 8, 0, 0, 1));
>>>>
>>>> Why not the simpler ui_out_field_int?
>>>> Going out of the way to print it in octal seems a bit odd for a machine
>>>> interface.
>>>>
>>>> Tom
>>>
>>> Agreed. I found that the exit code is often represented in octal (the 
>>> reason for this probably predates my birth). But for MI, it does not 
>>> matter.
>>
>> Though it might be a little less surprising if all places that print
>> the exit code print it the same way.  That way it's possible that
>> frontends just treat the exit code as a string, and present it as
>> is to the user.  They may already be doing that.
> 
> This is not a complex field to parse and output in whatever format. I don't see any
> value in leaving it octal just to save that amount of work to frontends. I mean, if a
> frontend can't parse a decimal number, how in the world does it use the rest of the MI. ;)

Sure, but that's not the point.  The point is that frontend might not
be _parsing_ the number _at all_, but just presenting it as a string
to the user as is (*).  I don't think we even document anywhere that
this MI field is a number.  With that in mind I don't think it's a good
idea to print the same info in different ways in different places.
The "if it ain't broke, don't fix it" principle would then lean on
keeping things octal, for consistency with what the user sees in the
console.
(Note you had missed updating at least one example in the manual.)

(*) - If I were writing a frontend that's what I'd do, as who knows
whether there's some target where the exit code might be best
presented some other way?  E.g., on Windows, it makes more sense
to present them in hex.

-- 
Pedro Alves


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