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

[John Baldwin <jhb@FreeBSD.org>]

On 3/21/19 9:12 AM, Pedro Alves wrote:
> On 03/21/2019 04:06 PM, Simon Marchi wrote:
>> On 2019-03-21 12:01, Eli Zaretskii wrote:
>>>> Date: Thu, 21 Mar 2019 11:02:00 -0400
>>>> From: Simon Marchi <simark@simark.ca>
>>>> Cc: tom@tromey.com, gdb-patches@sourceware.org
>>>>
>>>>> 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.
>>>>
>>>> There's not much difference in hex, you would just write "if
>>>> $_gdb_version >= 0x0901" for example, rather than "if $_gdb_version >=
>>>> 901".
> 
> Is there an advantage of a single variable that encodes the version,
> compared to separate major/minor variables?  Separate variables
> would render the discussion of how to encode this moot.
> 
> GCC has these as predefined preprocessor macros:
> 
>  __GNUC__
>  __GNUC_MINOR__
>  __GNUC_PATCHLEVEL__
> 
> We could likewise have separate variables for these.

I think splitting it out is perhaps the simplest.  FWIW, in FreeBSD we
have a single __FreeBSD_version macro that uses decimal.  We also had
some drama when we originally had a single digit field for the minor
version but had minor versions beyond 9 (4.10, 4.11).  The current
format is:

 * scheme is:  <major><two digit minor>Rxx
 *		'R' is in the range 0 to 4 if this is a release branch or
 *		X.0-CURRENT before releng/X.0 is created, otherwise 'R' is
 *		in the range 5 to 9.
 */
#undef __FreeBSD_version
#define __FreeBSD_version 1300013	/* Master, propagated to newvers */

So release 7.2 would be 702000 and each time a patch is issued to the
release due to an errata or security, the last two digits get bumped
(kind of like a patch number), e.g. 702001, 702002.  The 7.x branch
in between 7.2 and 7.3 is 702500 so it sorts between 7.2 release and
7.3 release.  FreeBSD also bumps the 'patch level' field somewhat
frequently even on 'master' as it's used to denote API (or ABI on
'master') changes.  This has mostly worked out ok, and I do think using
decimal is easier to "read" than hex for this, but split out version
numbers is probably simpler for users to work with.

-- 
John Baldwin