NetBSD Problem Report #59811

From www@netbsd.org  Sun Nov 30 21:05:26 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 83A601A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 30 Nov 2025 21:05:26 +0000 (UTC)
Message-Id: <20251130210525.584631A923A@mollari.NetBSD.org>
Date: Sun, 30 Nov 2025 21:05:25 +0000 (UTC)
From: jlduran@gmail.com
Reply-To: jlduran@gmail.com
To: gnats-bugs@NetBSD.org
Subject: strpct round-off error
X-Send-Pr-Version: www-1.0

>Number:         59811
>Category:       lib
>Synopsis:       strpct round-off error
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kre
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 30 21:10:00 +0000 2025
>Closed-Date:    Sat Dec 20 20:39:32 +0000 2025
>Last-Modified:  Sat Dec 20 20:39:32 +0000 2025
>Originator:     Jose Luis Duran
>Release:        trunk
>Organization:
FreeBSD
>Environment:
>Description:
While porting df tests to FreeBSD, I realized some percentages were incorrectly rounded.
The issue seems to be that df on NetBSD uses strspct(3) to compute the percentage. Apparently, it has issues rounding 66.6666... to 66.7 or 67.

With the mwe.c program below, we can replicate the issue.

>How-To-Repeat:
% cat mwe.c
#include <stdio.h>
#include <util.h>

int
main(void)
{
	char pb[64];

	strpct(pb, sizeof(pb), 1443260007, 2164890010, 1);

	printf(" Current: %s\n", pb);
	printf("Expected: 66.7\n");

	return (0);
}
% cc -lutil mwe.c
% ./a.out
 Current: 66.6
Expected: 66.7
>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: lib-bug-people->kre
Responsible-Changed-By: kre@NetBSD.org
Responsible-Changed-When: Tue, 02 Dec 2025 00:23:02 +0000
Responsible-Changed-Why:
I am looking into this PR


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
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
     Message-ID:  <20251130211000.A4F7E1A923C@mollari.NetBSD.org>


   | 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=1
 1443260007 * 100 / 2164890010
 66.6
 scale=20
 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.

   | 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.

 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?

 kre

From: Jose Luis Duran <jlduran@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kre@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
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> wrote:
 >
 > The following reply was made to PR lib/59811; it has been noted by GNATS.
 >
 > From: Robert Elz <kre@munnari.OZ.AU>
 > To: gnats-bugs@netbsd.org
 > 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
 >      Message-ID:  <20251130211000.A4F7E1A923C@mollari.NetBSD.org>
 >
 >
 >    | 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
 >

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/59811: strpct round-off error
Date: Tue, 02 Dec 2025 12:01:13 +0700

     Date:        Mon, 1 Dec 2025 22:28:44 -0300
     From:        Jose Luis Duran <jlduran@gmail.com>
     Message-ID:  <CAPwQLcfxrPwvA8RAJJp0asSVE=beiAzwrB-FWGBpzf9xPkgvog@mail.gmail.com>

   | Interesting, but also note that df[1] reads:

 Yes, when we're using -P we should be doing it that way.

 And rounding up (rather than rounding to nearest) does make
 sense for df -- I'm not sure it does for any other users we
 might have of str[s]pct though (I will do a check and discover
 what else, if anything, uses it - csh maybe, that's where it came
 from, and for that, round up is probably wrong).

 kre

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: kre@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	jlduran@gmail.com
Subject: Re: lib/59811: strpct round-off error
Date: Tue, 2 Dec 2025 11:30:37 +0100

 On Tue, Dec 02, 2025 at 12:35:01AM +0000, Robert Elz via gnats wrote:
 >  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?

 I would certainly expect it to work according to fenv(3)/fesetround(3)
 global rounding mode.

 Martin

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/59811: strpct round-off error
Date: Tue, 2 Dec 2025 13:58:09 -0000 (UTC)

 gnats-admin@NetBSD.org ("Martin Husemann via gnats") writes:

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

 >From: Martin Husemann <martin@duskware.de>
 > On Tue, Dec 02, 2025 at 12:35:01AM +0000, Robert Elz via gnats wrote:
 > >  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?
 > 
 > I would certainly expect it to work according to fenv(3)/fesetround(3)
 > global rounding mode.


 I wouldn't from a routine that explicitely says it does not use
 floating point arithmetic.

 str(s)pct is used by df and csh/time.

 I suggest to add a variant with explicit rounding mode (down/up/nearest/...),
 maybe change str(s)pct to use round-to-nearest (good for csh) and
 change df to use the round-up version to be compliant.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/59811: strpct round-off error
Date: Wed, 03 Dec 2025 00:51:43 +0700

     Date:        Tue,  2 Dec 2025 14:00:02 +0000 (UTC)
     From:        "Michael van Elst via gnats" <gnats-admin@NetBSD.org>
     Message-ID:  <20251202140002.556F21A923A@mollari.NetBSD.org>

   |  I wouldn't from a routine that explicitely says it does not use
   |  floating point arithmetic.

 Yes, nor would I.

   |  str(s)pct is used by df and csh/time.

 That's about what I expected, but I hadn't looked yet.

   |  I suggest to add a variant with explicit rounding mode
   | (down/up/nearest/...),

 I was considering instead a new function to set the desired rounding
 mode, which is unlikely to have up or down, but would have towards, and
 away from, zero, and perhaps nearest (but no magic 0.5 up/down alternating).

 Up and down (towards maxint or -maxint) would be difficult to deal with
 in the current implementation, which uses the unsigned (strpct) version
 to implement the signed one as well (just doing sign changes, and inserting
 a '-' into the result buffer if it is needed).  That is, the code that would
 be doing the rounding doesn't know if it is ultimately dealing with a positive
 or negative result, so can't tell which way it would need to round.

 I have (I think) a working "round away from zero" version now (without
 much added cost), and "round toward zero" is what it did before, round to
 nearest just means picking which of those two to apply in a particular case,
 and I had that working for a while too (before the actual round away code
 worked properly) but then deleted it when it was pointed out that df only
 wants round away (but I agree, for output from time, round to nearest makes
 more sense).

 kre

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/59811: strpct round-off error
Date: Wed, 03 Dec 2025 12:12:13 +0700

 I now have (what I believe to be) working code to fix this.

 I am including 2 potential manual pages - please tell me which one
 you prefer (as in, which style of the fix -- in the actual text, I
 worked on the 2nd version below after the first, and in the process
 improved its wording - I think - if the first one is the preferred
 method, I'll redo the wording of it to be more like the second).

 I also "enhanced" slightly the OP's mwe.c test program, to use in testing
 this - mwe2 takes args, with options for the rounding mode desired and the
 number of fractional digits (also the buffer size, but that's just for
 testing perverse stupid usages), its usage is:

 Usage: mwe2 [-f digits] [-r mode] [-s bufsize] [ numerator [ denominator ] ]

 And using that with the original numerator & denominator (as given in this
 PR, which remain the defaults) and with -f1 (to get one decimal place),
 with the 3 rounding modes, I see:

 jacaranda$ ./mwe2 -f1 -r0
  Current: 66.6
 Expected: 66.6
 jacaranda$ ./mwe2 -f1 -r1
  Current: 66.7
 Expected: 66.7
 jacaranda$ ./mwe2 -f1 -r2
  Current: 66.7
 Expected: 66.7

 Note that the "expected" value is now computed (in mwe2.c, using floating
 point) to be consistent with the -f and -r args given.

 In case it happens not to be obvious by its very nature, -r1 always
 produces the same output as either -r0 or -r2 (which depends upon the
 data).

 Then also:
 jacaranda$ ./mwe2 -f2 -r1
  Current: 66.67
 Expected: 66.67
 jacaranda$ ./mwe2 -f2 -r0
  Current: 66.66
 Expected: 66.66
 jacaranda$ ./mwe2 -f12 -r1
  Current: 66.666666682064
 Expected: 66.666666682064
 jacaranda$ ./mwe2 -f11 -r1
  Current: 66.66666668206
 Expected: 66.66666668206
 jacaranda$ ./mwe2 -f11 -r2
  Current: 66.66666668207
 Expected: 66.66666668207

 The current implementation uses the first of the man pages below, but
 changing it to be the second will take only about a minute, so ignore that.

 I believe these do need a method to specify which rounding style to use,
 how to do that is the difference between the two man pages below.  It would
 be easy to just not do that, and simply pick one of them (and since df's
 usage is fairly simple, it could adjust the args to force the rounding it
 is supposed to use, if the one and only style implemented were not the one
 that it requires.)

 These also presume that any changes implemented now will get pulled up
 to NetBSD 11 - that is by no means certain.  If it doesn't happen, the
 reference to .Nx 11.0 can easily turn into .Nx 12.0.

 I have tried to avoid inventing names for anything, as much as is possible,
 so please feel free to make suggestions for unnamed objects, or alterations
 where I invented one.

 So, here are the two possible manual pages (sorry, no visible markup here,
 which makes it harder to read, I know - it exists though):

 STRPCT(3)                  Library Functions Manual                  STRPCT(3)

 NAME
      strpct, strspct - decimal percent formatters

 LIBRARY
      System Utilities Library (libutil, -lutil)

 SYNOPSIS
      #include <util.h>

      char *
      strpct(char *buf, size_t bufsiz, uintmax_t numerator,
          uintmax_t denominator, size_t precision);

      char *
      strspct(char *buf, size_t bufsiz, intmax_t numerator,
          intmax_t denominator, size_t precision);

      int
      strpct_round(int mode);

 DESCRIPTION
      The strpct() function formats the fraction represented by numerator and
      denominator into a percentage representation with given number of digits
      of precision without using floating point arithmetic.

      The strspct() function is identical to strpct() except uses signed values
      for the numerator and denominator, and so can return a result with a
      leading minus sign.

      The result is rounded according to the current rounding mode, which for
      historical reasons defaults to rounding towards zero (that is truncating,
      as would be done using integer arithmetic).  This can be altered using
      strpct_round().  The mode specifies which of 3 implemented rounding modes
      to use.  If mode is given as zero, the default of rounding towards 0 (no
      rounding) is used.  If mode is given as 1, the least significant digit of
      the result returned will be rounded to the nearest correct value.  Values
      mid way between one digit and the next round away from zero.  If mode is
      given as 2, the least significant digit of the result will be incremented
      if there were any less significant non-zero digits not included in the
      result -- that is, rounded away from zero.  If mode is given as INT_MAX
      or -INT_MAX, the rounding will be set as for mode 0.  Those values are
      defined to allow for future implementation (unlikely to ever happen) of
      routing towards infinity (INT_MAX) or negative infinity (-INT_MAX).  Any
      other value for mode is simply igored, and the rounding mode is not
      changed.

 RETURN VALUES
      strpct() and strspct() always return a pointer to a NUL-terminated
      (unless bufsiz is 0) formatted string which is placed in buf.
      strpct_round() returns the rounding mode that was in use before the call.
      To obtain this information without altering the rounding mode, call
      strpct_round() with a mode of -1.

 EXAMPLES
            strpct(buf, sizeof(buf), 1, 16, 3);
            => "6.250"
            strpct(buf, sizeof(buf), 1, 2, 0);
            => "50"

 HISTORY
      strpct() was originally implemented in csh(1) for NetBSD 1.3.  It printed
      into a static buffer, was not locale aware, handled unsigned long
      numbers, and printed a "%" at the end of the number.  Other programs such
      as df(1) and time(1) started using it.  strpct() and strspct() appeared
      separately in libutil for NetBSD 6.0.

      strpct_round() appeared in NetBSD 11.0.

 AUTHORS
      Erik E. Fair <fair@NetBSD.org>
      Roland Illig <rillig@NetBSD.org>

 NetBSD 11.99.4                 December 3, 2025                 NetBSD 11.99.4


 or, an alternative:

 STRPCT(3)                  Library Functions Manual                  STRPCT(3)

 NAME
      strpct, strspct, strpct_r, strspct_r - decimal percent formatters

 LIBRARY
      System Utilities Library (libutil, -lutil)

 SYNOPSIS
      #include <util.h>

      char *
      strpct(char *buf, size_t bufsiz, uintmax_t numerator,
          uintmax_t denominator, size_t precision);

      char *
      strpct_r(char *buf, size_t bufsiz, uintmax_t numerator,
          uintmax_t denominator, size_t precision, int rounding_mode);

      char *
      strspct(char *buf, size_t bufsiz, intmax_t numerator,
          intmax_t denominator, size_t precision);

      char *
      strspct_r(char *buf, size_t bufsiz, intmax_t numerator,
          intmax_t denominator, size_t precision, int rounding_mode);

 DESCRIPTION
      The strpct_r() function formats the fraction represented by numerator and
      denominator into a percentage representation with given number of digits
      of precision without using floating point arithmetic.

      The result is stored in the buf in which a maximum of bufsiz - 1
      meaningful bytes can be stored, and is rounded according to the
      rounding_mode.  The current locale's radix character, typically period
      (`.') or comma (`,'), is inserted before fractional digits if the
      precision is greater than 0.  If rounding_mode is given as zero, rounding
      towards 0 (truncating rather than rounding) is used.  If rounding_mode is
      given as 1, the result returned will be rounded to the nearest correct
      value.  Actual values exactly mid way between one representable value and
      the next round away from zero.  If rounding_mode is given as 2, the
      result will be rounded, if needed, to the next value further away from
      zero.

      The strspct_r() function is identical to strpct_r() except uses signed
      values for the numerator and denominator, and so can return a result with
      a leading minus sign.

      The strpct() and strspct() functions are identical to strpct_r() and
      strspct_r() respectively, with the rounding_mode specified as zero.

 RETURN VALUES
      strpct_r(), strspct_r(), strpct() and strspct() always return a pointer
      to a NUL-terminated (unless bufsiz is 0) formatted string which is placed
      in buf.

 EXAMPLES
            strpct(buf, sizeof(buf), 1, 16, 3);
            => "6.250"
            strpct(buf, sizeof(buf), 1, 2, 0);
            => "50"

 HISTORY
      strpct() was originally implemented in csh(1) for NetBSD 1.3.  It printed
      into a static buffer, was not locale aware, handled unsigned long
      numbers, and printed a "%" at the end of the number.  Other programs such
      as df(1) and time(1) started using it.  strpct() and strspct() appeared
      separately in libutil for NetBSD 6.0.

      strpct_r() and strspct_r() appeared in NetBSD 11.0.

 AUTHORS
      Erik E. Fair <fair@NetBSD.org>
      Roland Illig <rillig@NetBSD.org>

 BUGS
      If the supplied buffer size is insufficient for the result (including a
      terminating nul (`\0') character), the result will be silently truncated
      with only the most significant digits included, the last of which will be
      rounded using the requested method.  This is not useful.  If the buffer
      space is exhausted part way through a locale's (multi-byte) radix
      character, even more bizarre behaviour is to be expected.  Always provide
      a buffer bigger than can possibly be needed.

      Rather than causing an abnormal process termination, as it arguably
      should, a denominator specified as zero will be treated as if it were
      one.

 NetBSD 11.99.4                 December 3, 2025                 NetBSD 11.99.4


From: Jose Luis Duran <jlduran@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kre@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: lib/59811: strpct round-off error
Date: Wed, 3 Dec 2025 02:56:37 -0300

 On Wed, Dec 3, 2025 at 2:25=E2=80=AFAM Robert Elz via gnats
 <gnats-admin@netbsd.org> wrote:
 >
 > The following reply was made to PR lib/59811; it has been noted by GNATS.
 >
 > From: Robert Elz <kre@munnari.OZ.AU>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: lib/59811: strpct round-off error
 > Date: Wed, 03 Dec 2025 12:12:13 +0700
 >
 >  I now have (what I believe to be) working code to fix this.
 >
 >  I am including 2 potential manual pages - please tell me which one
 >  you prefer

 Not that I get to vote, but you have sold me on manual page #1.
 I never thought opening this simple bug report would be so
 interesting. Thank you!

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: lib/59811: strpct round-off error
Date: Tue, 09 Dec 2025 11:49:40 +0700

     Date:        Wed, 3 Dec 2025 02:56:37 -0300
     From:        Jose Luis Duran <jlduran@gmail.com>
     Message-ID:  <CAPwQLcc2Rx1PBkjf-QwFOPDFgDPTPau8+yQBNpj+2a+KdEohQw@mail.gmail.com>

   | >  I am including 2 potential manual pages - please tell me which one
   | >  you prefer

 Everyone should note that the "you" there was generic, feel free to
 comment...

   | Not that I get to vote, but you have sold me on manual page #1.

 The more I think about it the more I think that #2 is better - the
 functions remain thread safe (even async signal safe, probably) that way.
 That wouldn't matter to any current user of them, but is better I think.

 I will wait a few more days for anyone else who wants to comment to do so
 (go read the PR if you missed the initial discussion.)

 kre

From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59811 CVS commit: src
Date: Sun, 14 Dec 2025 16:28:06 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Sun Dec 14 16:28:05 UTC 2025

 Modified Files:
 	src/bin/df: df.c
 	src/distrib/sets/lists/base: shl.mi
 	src/distrib/sets/lists/debug: shl.mi
 	src/doc: CHANGES
 	src/include: util.h
 	src/lib/libutil: shlib_version strpct.3 strpct.c util.expsym

 Log Message:
 PR lib/59811  allow any rounding in strpct(3).

 Add str[s]pct_r (same as str[s]pct with an addition "how to round" param) and
 strpct_round to set the rounding used by the older str[s]pct functions.
 The default remains rounding down (toward zero) for compatibility.

 See the PR (and the updated man page) for the details.

 For df(1) use "round away from zero" mode, as POSIX requires.

 XXX pullup -11


 To generate a diff of this commit:
 cvs rdiff -u -r1.104 -r1.105 src/bin/df/df.c
 cvs rdiff -u -r1.1017 -r1.1018 src/distrib/sets/lists/base/shl.mi
 cvs rdiff -u -r1.378 -r1.379 src/distrib/sets/lists/debug/shl.mi
 cvs rdiff -u -r1.3206 -r1.3207 src/doc/CHANGES
 cvs rdiff -u -r1.70 -r1.71 src/include/util.h
 cvs rdiff -u -r1.54 -r1.55 src/lib/libutil/shlib_version
 cvs rdiff -u -r1.7 -r1.8 src/lib/libutil/strpct.3
 cvs rdiff -u -r1.6 -r1.7 src/lib/libutil/strpct.c
 cvs rdiff -u -r1.1 -r1.2 src/lib/libutil/util.expsym

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: lib/59811: strpct round-off error
Date: Sun, 14 Dec 2025 23:40:52 +0700

 The changes for this are committed now, and will (in a few days probably)
 get requested for pullup to -11 (not to anything earlier than that).

 I decided to go with a hybrid (union) of both earlier suggested methods.
 As I indicated in the previous message (last Tues) I believe that the
 strpct_r (etc) version is the way forward.

 Then I looked at the strpct tests ... I just couldn't face updating all
 of that with changed default rounding, or not this week anyway, so if
 things had been left as stated, that test would have failed.

 The only way to avoid that, which I have done - and which is also probably
 the right thing for backward compat, is to keep the older strpct() and
 strspct() doing "round toward zero" as they have always done, rather than
 changing them to be "round to nearest" which is a more rational default.

 So, that's what I did.

 But rather than condemn those functions to always be that, meaning that
 the (very few) uses of them would probably change to use the new versions,
 for better rounding, I added the strpct_round() function, to allow the
 default rounding mode to be altered - and then added a call to that in df(1)
 to set its rounding mode to "round away from zero" as POSIX requires (which
 seems to be working just fine - one of my filesystems reports 41% full with
 the modified df, just 40% full with the old one).

 We can perhaps revisit changing the default rounding mode for strpct and
 strspct sometime later.

 Otherwise, unless someone can break the updated code, I think this is done
 (after the pullup happens).

 kre


State-Changed-From-To: open->needs-pullups
State-Changed-By: kre@NetBSD.org
State-Changed-When: Sun, 14 Dec 2025 16:46:03 +0000
State-Changed-Why:
pullup to -11 to come


From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59811 CVS commit: src/tests/bin/df
Date: Sun, 14 Dec 2025 22:15:20 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Sun Dec 14 22:15:20 UTC 2025

 Modified Files:
 	src/tests/bin/df: t_df.sh

 Log Message:
 Adjust expected df output percentages (PR lib/59811 related)

 df now rounds percentages up, as POSIX specifies, rather than
 down, as it used to.   Adjust the expected output (add 1 to many
 of the entries in the percentage column) to compensate for this
 change.

 XXX pullup -11


 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.4 src/tests/bin/df/t_df.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: kre@NetBSD.org
State-Changed-When: Sat, 20 Dec 2025 12:42:27 +0000
State-Changed-Why:
[pullup-11 #134]


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59811 CVS commit: [netbsd-11] src
Date: Sat, 20 Dec 2025 13:51:20 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Dec 20 13:51:20 UTC 2025

 Modified Files:
 	src/bin/df [netbsd-11]: df.c
 	src/distrib/sets/lists/base [netbsd-11]: shl.mi
 	src/distrib/sets/lists/debug [netbsd-11]: shl.mi
 	src/include [netbsd-11]: util.h
 	src/lib/libutil [netbsd-11]: shlib_version strpct.3 strpct.c
 	    util.expsym
 	src/tests/bin/df [netbsd-11]: t_df.sh

 Log Message:
 Pull up following revision(s) (requested by kre in ticket #134):

 	lib/libutil/util.expsym: revision 1.2
 	lib/libutil/shlib_version: revision 1.55
 	distrib/sets/lists/base/shl.mi: revision 1.1018
 	lib/libutil/strpct.c: revision 1.7
 	lib/libutil/strpct.3: revision 1.8
 	distrib/sets/lists/debug/shl.mi: revision 1.379
 	tests/bin/df/t_df.sh: revision 1.4
 	bin/df/df.c: revision 1.105
 	include/util.h: revision 1.71

 PR lib/59811  allow any rounding in strpct(3).

 Add str[s]pct_r (same as str[s]pct with an addition "how to round" param) and
 strpct_round to set the rounding used by the older str[s]pct functions.
 The default remains rounding down (toward zero) for compatibility.
 See the PR (and the updated man page) for the details.

 For df(1) use "round away from zero" mode, as POSIX requires.

 Adjust expected df output percentages (PR lib/59811 related)
 df now rounds percentages up, as POSIX specifies, rather than
 down, as it used to.   Adjust the expected output (add 1 to many
 of the entries in the percentage column) to compensate for this
 change.


 To generate a diff of this commit:
 cvs rdiff -u -r1.104 -r1.104.2.1 src/bin/df/df.c
 cvs rdiff -u -r1.1008.2.1 -r1.1008.2.2 src/distrib/sets/lists/base/shl.mi
 cvs rdiff -u -r1.367.2.2 -r1.367.2.3 src/distrib/sets/lists/debug/shl.mi
 cvs rdiff -u -r1.70 -r1.70.2.1 src/include/util.h
 cvs rdiff -u -r1.54 -r1.54.30.1 src/lib/libutil/shlib_version
 cvs rdiff -u -r1.7 -r1.7.2.1 src/lib/libutil/strpct.3
 cvs rdiff -u -r1.6 -r1.6.2.1 src/lib/libutil/strpct.c
 cvs rdiff -u -r1.1 -r1.1.2.1 src/lib/libutil/util.expsym
 cvs rdiff -u -r1.3 -r1.3.4.1 src/tests/bin/df/t_df.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: pending-pullups->closed
State-Changed-By: kre@NetBSD.org
State-Changed-When: Sat, 20 Dec 2025 20:39:32 +0000
State-Changed-Why:
Pullups completed


>Unformatted:

Home	PR Database Search