Re: kern/60810: /usr/src/sys/conf/osrelease.h -s behavior does not match description

["Rob Whitlock via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60810; it has been noted by GNATS.

From: Rob Whitlock <rwhitlock22%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/60810: /usr/src/sys/conf/osrelease.h -s behavior does not
 match description
Date: Mon, 28 Sep 2026 17:22:40 -0400

 > On Sep 27, 2026, at 5:15 PM, Robert Elz via gnats =
 <gnats-admin%NetBSD.org@localhost> wrote:
 >=20
 > The following reply was made to PR kern/60810; it has been noted by =
 GNATS.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:=20
 > Subject: Re: kern/60810: /usr/src/sys/conf/osrelease.h -s behavior =
 does not match description
 > Date: Mon, 28 Sep 2026 04:11:25 +0700
 >=20
 >     Date:        Sun, 27 Sep 2026 02:55:00 +0000 (UTC)
 >     From:        "rwhitlock22%gmail.com@localhost via gnats" =
 <gnats-admin%NetBSD.org@localhost>
 >     Message-ID:  <20260927025500.E901A1A923E%mollari.NetBSD.org@localhost>
 >=20
 >=20
 >   | thinkpad# sh osrelease.sh -s
 >   | 11998
 >   | thinkpad#=20
 >   |
 >   | but it should have output
 >   |
 >   | 119908
 >=20
 > If this were to change, it should be to 1199008 .. we have had =
 instances
 > before (well, one instance) where the "pp" part went above 99.  It =
 could
 > actually use 4 digits I believe, but it is hard to imagine that ever
 > happening.
 
 That is a fair concern.
 
 > But I'm not sure this is really needed, none of the XX symbols for the
 > various forms are intended to imply that 2 characters will appear.
 >=20
 > For example, the comments say
 >=20
 > # default: return MM.mm.pp=20
 > # -m: return MM, representing only the major number; however, for =
 -current,
 > #     return the next major number (e.g. for 5.99.nn, return 6)
 >=20
 > That is, in that case "MM" is 6 (not 2 digits).   The same is true of
 > mm, for 11.1 that will be "1" I expect, or for 10.3 it would be "3".
 > "pp" is no different.
 
 I agree that when the decimal points are printed, then the leading zeros
 are not necessary. However, I am arguing about the -s MMmmpp case, not
 the -m MM.mm.pp case.
 
 I think that MM being one digit is a special case because that does not
 break the ability to correctly compare two versions written without
 any decimal point separator. On the other hand, having mm or pp be one
 digit does change this ability to correctly compare the two versions.
 
 I see it as the same notation used in the synopsis of the date(1)
 man page, where you have [[[[[[CC]yy]mm]dd]HH]MM[.SS] and each of those
 fields is two characters wide and filled out with leading zeros if
 necessary. So the interpretation of the comments for the -s option
 specifying fixed-width zero-padded fields is not unreasonable.
 
 In pkgsrc/doc/HOWTO-use-crosscompile, there are instructions to set
 the variable CROSS_OPSYS_VERSION as such for NetBSD 10.0:
 
 CROSS_OPSYS_VERSION=3D 100000
 
 While one could guess at what this format is, we can determine what that
 format is by looking at the output of
 
 make help topic=3DOPSYS_VERSION
 
 which shows us that bsd.prefs.mk generates NATIVE_OPSYS_VERSION as
 a MMmmpp-format integer string where the fields are zero-padded.
 OPSYS_VERSION is set in bsd.prefs.mk by choosing between
 NATIVE_OPSYS_VERSION and CROSS_OPSYS_VERSION. Therefore, each of
 OPSYS_VERSION, NATIVE_OPSYS_VERSION, and CROSS_OPSYS_VERSION
 are of the same format. We can furthermore verify with the command
 
 grep -r OPSYS_VERSION /usr/pkgsrc/mk
 
 that OPSYS_VERSION is used to compare against specific version
 integers in the MMmmpp format.
 
 Given that CROSS_OPSYS_VERSION is in the MMmmpp format, and
 osrelease.sh advertises its -s output as being in the MMmmpp
 format, it is reasonable for someone to assume that you could
 take the output of osrelease.sh -s and put it directly into the
 CROSS_OPSYS_VERSION variable. However, if osrelease -s does not
 maintain fixed-width fields, then this becomes a foot gun that
 people may hurt themselves with when pkgsrc's version comparisons
 (perhaps invisibly) no longer work correctly.
 
 Now it could very well be that we should not consider
 osrelease.sh -s to be at fault, and that the output of
 osrelease.sh -s should not be directly written to
 CROSS_OPSYS_VERSION, and users of the pkgsrc cross-compile
 framework should build up the CROSS_OPSYS_VERSION value themselves.
 But in that case, I would highly recommend that the comments in=20
 osrelease.sh be explicit about the possiblity for the individual=20
 fields in the -s output to be only one character wide instead of
 two, without the unstated requirement for the users to read the
 code and infer corner case behavior.
 
 That would, however, still leave the problem that a given
 osrelease.sh -s output does not uniquely specify a particular
 version, as certain digits could be attributable to multiple
 fields. If there are no programs trying to parse this output
 into its constituent fields then this would not be a programming
 problem, but it could still be confusing for humans.
 
 > I would also advise against simply comparing any of these as numbers
 > in the form osrelease.sh generates them - if one wants to compare
 > numeric kernel versions, simply compare the numeric value from
 > __NetBSD_Version__ rather than extracting bits of it and comparing =
 that.
 
 Noted. However, when it appears to be the same format as what another
 variable (CROSS_OPSYS_VERSION) uses, it can be tempting to use it.
 
 > I don't see anything (not the script code, nor its comments) that =
 needs
 > fixing here for this issue (the sh code however could do with some =
 work).
 >=20
 > kre
 >=20
 >=20