Re: [PATCH 2/2] doc: Improve documentation about MI thread output

[Eli Zaretskii <eliz at gnu dot org>]

> CC: <gdb-patches@sourceware.org>
> From: Simon Marchi <simon.marchi@ericsson.com>
> 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.