From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17135 invoked by alias); 21 Mar 2019 16:54:20 -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 17118 invoked by uid 89); 21 Mar 2019 16:54:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:sk:server-, 7.2, 72, 7x X-HELO: mx2.freebsd.org Received: from mx2.freebsd.org (HELO mx2.freebsd.org) (8.8.178.116) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Mar 2019 16:54:17 +0000 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 57FE797BA0; Thu, 21 Mar 2019 16:54:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 633A26D2BD; Thu, 21 Mar 2019 16:54:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 749DC18FFB; Thu, 21 Mar 2019 16:54:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH 00/16] Add styling to the gdb CLI and TUI To: Pedro Alves , Simon Marchi , Eli Zaretskii Cc: tom@tromey.com, gdb-patches@sourceware.org References: <20181128001435.12703-1-tom@tromey.com> <83k1kxfzwo.fsf@gnu.org> <8736rja4i8.fsf@tromey.com> <83r2brhw8k.fsf@gnu.org> <87h8cmh1wg.fsf@tromey.com> <83va12gz8j.fsf@gnu.org> <87mumeb935.fsf@tromey.com> <83d0n8eyzw.fsf@gnu.org> <87d0n6adk2.fsf@tromey.com> <83imwyee29.fsf@gnu.org> <87d0n67d29.fsf@tromey.com> <83imwwc7pj.fsf@gnu.org> <57558f60-8254-931f-846b-bdd6b60f5798@simark.ca> <838sx8uwbb.fsf@gnu.org> <834l7wushq.fsf@gnu.org> <0f1760b45f024d45ceece8f0fe5c2686@simark.ca> From: John Baldwin Openpgp: preference=signencrypt Message-ID: Date: Thu, 21 Mar 2019 16:54:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 633A26D2BD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00462.txt.bz2 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 >>>> 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: 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