From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100960 invoked by alias); 12 Apr 2017 20:34:48 -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 100932 invoked by uid 89); 12 Apr 2017 20:34:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=claim X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Apr 2017 20:34:46 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cyOyQ-0007z4-TT for gdb-patches@sourceware.org; Wed, 12 Apr 2017 16:34:46 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyOyQ-0007z0-Pe; Wed, 12 Apr 2017 16:34:42 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1358 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cyOyP-0002YP-Vk; Wed, 12 Apr 2017 16:34:42 -0400 Date: Wed, 12 Apr 2017 20:34:00 -0000 Message-Id: <83o9w1icug.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org In-reply-to: (message from Simon Marchi on Wed, 12 Apr 2017 16:09:35 -0400) Subject: Re: [PATCH 2/2] doc: Improve documentation about MI thread output Reply-to: Eli Zaretskii References: <20170412180610.2565-1-simon.marchi@ericsson.com> <20170412180610.2565-2-simon.marchi@ericsson.com> <83y3v5igdx.fsf@gnu.org> <83tw5tifpq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00370.txt.bz2 > CC: > From: Simon Marchi > Date: Wed, 12 Apr 2017 16:09:35 -0400 > > > I think we need to describe at least the most "popular" situations > > where this happens. The initial state of GDB is not an interesting > > case, but others are. In particular, IMO it would be good to state > > that when there's only one inferior being debugged that has been run > > already, there will always be a selected thread. > > I agree that we could give an example of situation where there _isn't_ > a selected thread. Readers may, like you did, find that it's an odd > claim and wonder how it's possible that there isn't a selected thread. > But I don't think it's useful (and maybe even counterproductive) to try > to define some situation where the field will always be present. > > The important thing that users of this API need to know is that the field > may not be there. This will encourage them to program defensively and check > whether the field is present before trying to use it. If we try to define a > green zone where the field is supposedly always be present, it will incite some > people to skip the check, which will potentially come back and bite them if the > behavior of GDB changes or there's a situation we haven't thought of where it > can happen. IME, defensive programming aside, knowing that some field could or could not appear is not always enough, sometimes you also need to understand the semantics and the significance of whether it does or doesn't, because you might need to interpret that in some way, e.g. to present some meaningful message to a human user. That said, I'm not going to argue. It's up to you.