From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28147 invoked by alias); 2 Jun 2014 19:23:18 -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 28136 invoked by uid 89); 2 Jun 2014 19:23:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Jun 2014 19:23:16 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s52JND3C015443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jun 2014 15:23:14 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s52JNCmx007532; Mon, 2 Jun 2014 15:23:12 -0400 Message-ID: <538CCF1F.5000902@redhat.com> Date: Mon, 02 Jun 2014 19:23:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Simon Marchi , Tom Tromey CC: gdb-patches@sourceware.org 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> In-Reply-To: <538CC2CD.9040309@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00040.txt.bz2 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. (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