Re: lib/59811: strpct round-off error

["Jose Luis Duran via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Jose Luis Duran <jlduran%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kre%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/59811: strpct round-off error
Date: Mon, 1 Dec 2025 22:28:44 -0300

 On Mon, Dec 1, 2025 at 9:35=E2=80=AFPM Robert Elz via gnats
 <gnats-admin%netbsd.org@localhost> wrote:
 >
 > The following reply was made to PR lib/59811; it has been noted by GNATS.
 >
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: lib/59811: strpct round-off error
 > Date: Tue, 02 Dec 2025 07:33:44 +0700
 >
 >      Date:        Sun, 30 Nov 2025 21:10:00 +0000 (UTC)
 >      From:        jlduran%gmail.com@localhost
 >      Message-ID:  <20251130211000.A4F7E1A923C%mollari.NetBSD.org@localhost>
 >
 >
 >    | While porting df tests to FreeBSD, I realized some percentages
 >    | were incorrectly rounded.
 >
 >  Hmm.   If I do the same calculation in bc (whose manual does say that
 >  it truncates the results from divide operations) I see the same thing:
 >
 >  scale=3D1
 >  1443260007 * 100 / 2164890010
 >  66.6
 >  scale=3D20
 >  1443260007 * 100 / 2164890010
 >  66.66666668206390771787
 >
 >  I'm not certain that having df give answers different than what bc
 >  would give were the user to use that to calculate the values, is
 >  necessarily a good idea.
 
 Interesting, but also note that df[1] reads:
 The percentage value shall be expressed as a positive integer, with
 any fractional result causing it to be rounded to the next highest
 integer.
 That is at least when using the -P flag.
 [1]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/df.html
 
 >    | Apparently, it has issues rounding 66.6666... to 66.7 or 67.
 >
 >  ["it" being strpct(3) of course]
 >
 >  That, or it simply implements "round towards 0" for all operations.
 >
 >  I will allow others to ponder a little upon what result we should be
 >  producing here (in the grand scheme of things I doubt it matters a lot)
 >  while I take a look to see how strpct() might be adapted to do "rounding
 >  to nearest" which is what I assume you're expecting it to do.
 
 Yes, I agree it is a low-priority issue.
 
 >  Maybe we need variants of str[s]pct() with a flags arg to indicate which
 >  kind of rounding is desired, or would that be way over the top?
 
 My personal opinion is that it would be over the top. I like the
 overall idea of strpct(3), if this is the expected behavior, a test or
 a simple paragraph in the manual page will suffice.
 Thank you for looking into it!
 
 >  kre
 >