Re: [PATCH 00/16] Add styling to the gdb CLI and TUI

[Eli Zaretskii <eliz@gnu.org>]

> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Wed, 20 Mar 2019 21:55:43 -0400
> 
> Ah, I noticed this because you changed the subject in your ping :).

The original one evidently failed to draw attention ;-)

> This would be very useful, especially that we can quite easily query
> this from MI as well as Python.

Thanks, I agree.

> > --- a/gdb/doc/gdb.texinfo
> > +++ b/gdb/doc/gdb.texinfo
> > @@ -11197,7 +11197,7 @@
> >  @vindex $_tlb@r{, convenience variable}
> >  The variable @code{$_tlb} is automatically set when debugging
> >  applications running on MS-Windows in native mode or connected to
> > -gdbserver that supports the @code{qGetTIBAddr} request. 
> > +gdbserver that supports the @code{qGetTIBAddr} request.
> >  @xref{General Query Packets}.
> >  This variable contains the address of the thread information block.
> 
> This looks like an unintended change.

No, it's not unintended.  I mentioned that in my preamble:

> (Note that I took this opportunity to clean up whitespace in top.c,
> I hope it's OK to do that as part of unrelated code changes.)

> I know we plan to move to a version scheme where we don't have a "patch"
> number (a third number), but just in case, maybe we could plan for it anyway
> just in case it ever changes again in the future (I don't expect it will,
> but we never know.
> 
> So something like MAJOR * 10000 + MINOR * 100 + PATCH * 100
> 
> Also, it means that in your example, 9.11.90 would produce 091190.  I think
> it's better if we are able to distinguish 9.11.90 from 9.12.

The idea was that we don't need to distinguish between them.  This
feature is intended to be used in scripts that need to know when a
certain feature became available, so IMO resolution below XX.YY is not
needed, because any XX.YY.ZZ version is just a snapshot of XX.YY+1.

> Also, we should consider doing like Python does, and encode different numbers
> in different bytes:
> 
>   https://docs.python.org/3/c-api/apiabiversion.html
> 
> So we could say ((MAJOR << 16) | (MINOR << 8) | PATCH), for example.  The
> advantage with this is that it's easy to to isolate a particular number
> using bitshifts and masks.  I know it would be possible as well in decimal
> to isolate a particular number, but it's just more convenient in hex.

I don't have a strong opinion, but I do have a weak one: the decimal
"encoding" makes it much easier for humans to construct version
numbers, they don't need to convert to hex.

> > -   As remote.c is used much more than remote-e7000.c, it was changed 
> > +   As remote.c is used much more than remote-e7000.c, it was changed
> >     back to 2 seconds in 1999.  */
> 
> Some more unintended changes?

It's intended, see above.

Thanks for the review.