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

[Rob Whitlock <rwhitlock22%gmail.com@localhost>]

> On Sep 27, 2026, at 5:15 PM, Robert Elz via gnats <gnats-admin%NetBSD.org@localhost> wrote:
> 
> The following reply was made to PR kern/60810; it has been noted by GNATS.
> 
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc: 
> 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
> 
>     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>
> 
> 
>   | thinkpad# sh osrelease.sh -s
>   | 11998
>   | thinkpad# 
>   |
>   | but it should have output
>   |
>   | 119908
> 
> 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.
> 
> For example, the comments say
> 
> # default: return MM.mm.pp 
> # -m: return MM, representing only the major number; however, for -current,
> #     return the next major number (e.g. for 5.99.nn, return 6)
> 
> 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= 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=OPSYS_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 
osrelease.sh be explicit about the possiblity for the individual 
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).
> 
> kre
> 
>