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

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 12 Jun 2023 11:11:47 UTC

            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

It comes down to this:

$ seq 1050000 1050000

I've been able to track down the offending commit, which is

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

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