Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
seq(1): drop a workaround in seq(1) causing bad number of lines
This would previously result in behavior like: $ seq 1 1050000|wc -l 1050001 The reason being something like this: $ seq 1050000 1050000 1.05e+06 1.05e+06 The source of the issue is the following commit: freebsd/freebsd-src@3049d4c The problem is that 'cur' and 'last_shown_value' will never not be not equal, as 'cur' is always incremented past the 'last' boundary in order to break the loop. As far as I can tell, there is no reliable way to check if there was a bad increment due to rounding error, so we should probably disregard those cases. The checking of whether we were dealing with integers is not reliable here either. The default %g format will truncate for any value over 999999. The double type can represent a lot larger range of integer values than that; treating them as truncating floats is wrong. Revert for now, until a better solution can be found.
- Loading branch information
Showing
2 changed files
with
75 additions
and
30 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters