[Bug 271964] seq(1) printing one line more than it should for many inputs since at least early 2018

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271964

            Bug ID: 271964
           Summary: seq(1) printing one line more than it should for many
                    inputs since at least early 2018
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: daniel@octaforge.org

Currently running the following will get you incorrect results:

$ seq 1 1050000|wc -l
 1050001

It comes down to this:

$ seq 1050000 1050000
1.05e+06
1.05e+06

I've been able to track down the offending commit, which is
https://github.com/freebsd/freebsd-src/commit/3049d4ccc031e5d4d0ff6b9a2445131f507778f2

As I see it, the logic of that commit is wrong and will result in false
positives more often than not in practice. The %g format string which is used
by default will truncate any value over 999999. The decimal precision of a
double type is much larger than that, as double has 53-bit mantissa. While at
it, the condition that 'cur != last_shown_value' will *always* be true, as the
'cur' will *always* need to increment past the end in order to break the loop
at all.

I don't see any reliable way to check this, actually. I don't think it is
actually possible to check if a rounding error happened or not. Therefore, I
think the above change should be reverted, unless somebody has a better idea.

This likely affects other BSDs as well, as it was found thanks to
https://floss.social/@Gottox@chaos.social/110527807611326720 - but I'm
reporting it here as I work primarily with FreeBSD sources and reverted it in
my project
(https://github.com/chimera-linux/chimerautils/commit/1ecc1e99d4a309631e846a868b5a422f996704ac).

-- 
You are receiving this mail because:
You are the assignee for the bug.