From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6206 invoked by alias); 2 Jun 2014 20:20:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6195 invoked by uid 89); 2 Jun 2014 20:20:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 02 Jun 2014 20:20:50 +0000 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 46.66.11744.5D98C835; Mon, 2 Jun 2014 16:27:33 +0200 (CEST) Received: from [142.133.110.254] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 2 Jun 2014 16:20:46 -0400 Message-ID: <538CDC9E.9020506@ericsson.com> Date: Mon, 02 Jun 2014 20:20:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pedro Alves CC: , Tom Tromey Subject: Re: [PATCH v5] Exit code of exited inferiors in -list-thread-groups References: <1400018204-29559-1-git-send-email-simon.marchi@ericsson.com> <87mweh31qi.fsf@fleche.redhat.com> <537CE38B.7040000@ericsson.com> <537CEBCB.5020401@redhat.com> <538CC2CD.9040309@ericsson.com> <538CCF1F.5000902@redhat.com> In-Reply-To: <538CCF1F.5000902@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00041.txt.bz2 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 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.