Re: [PATCH v5] Exit code of exited inferiors in -list-thread-groups

[Simon Marchi <simon dot marchi at ericsson dot com>]

On Mon 02 Jun 2014 03:23:11 PM EDT, Pedro Alves wrote:
> 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.

I had forgotten that the exit-code was already displayed somewhere else in the MI. Indeed,
having the same field in different formats in different records would make a very bad interface.

Speaking of which, the documentation for the *stopped record does not mention exit-code at
all. I think it should, since it appears in it when the exit code is not 0.

> (Note you had missed updating at least one example in the manual.)

I am not sure I understand. The examples in the -list-thread-groups command section? If so, I
believe they should not contain a exit-code field, as the process is running.

> (*) - 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.

Ah ok, I didn't realize that.