Re: lib/59811: strpct round-off error

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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: 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@localhost>
     Message-ID:  <20251202140002.556F21A923A%mollari.NetBSD.org@localhost>
 
   |  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