This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v5] Exit code of exited inferiors in -list-thread-groups
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 02 Jun 2014 20:23:11 +0100
- Subject: Re: [PATCH v5] Exit code of exited inferiors in -list-thread-groups
- Authentication-results: sourceware.org; auth=none
- References: <1400018204-29559-1-git-send-email-simon dot marchi at ericsson dot com> <87mweh31qi dot fsf at fleche dot redhat dot com> <537CE38B dot 7040000 at ericsson dot com> <537CEBCB dot 5020401 at redhat dot com> <538CC2CD dot 9040309 at ericsson dot com>
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