seq will loop forever on large numbers

[jaggededgedjustice]

When seq is used to generate very large numbers it will get stuck in an infinite loop.

The gnu coreutils test includes the following check:

seq 999999999999999999999999999999999999999999999999999999999999999999999999999999999 1000000000000000000000000000000000000000000000000000000000000000000000000000000001

The expected output is:

$ seq 999999999999999999999999999999999999999999999999999999999999999999999999999999999 1000000000000000000000000000000000000000000000000000000000000000000000000000000001
999999999999999999999999999999999999999999999999999999999999999999999999999999999
1000000000000000000000000000000000000000000000000000000000000000000000000000000000
1000000000000000000000000000000000000000000000000000000000000000000000000000000001

The actual output is:

$ ./target/debug/coreutils seq 999999999999999999999999999999999999999999999999999999999999999999999999999999999 1000000000000000000000000000000000000000000000000000000000000000000000000000000001 
999999999999999921281879895665782741935503249059183851809998224123064148429897728
999999999999999921281879895665782741935503249059183851809998224123064148429897728
999999999999999921281879895665782741935503249059183851809998224123064148429897728
<repeat forever>

[sylvestre]

This is the cause of the timeout you were mentioning ?

[sylvestre]

@nbraud as it is about numbers and stuff, would you like to fix this bug? :)
Merci!

[jaggededgedjustice]

This is 1 error that cause the GNU tests to hang, though #1704 is the cause of the hang I mentioned before.

[verhovsky]

GNU seq must be using a different data type when you pass in integers. It has the same issue when you pass in floats:

$ seq 999999999999999999999999999999999999999999999999999999999999999999999998 999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999998
999999999999999999999999999999999999999999999999999999999999999999999999
$ seq 999999999999999999999999999999999999999999999999999999999999999999999998.0 999999999999999999999999999999999999999999999999999999999999999999999999.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
1000000000000000000025241104311868515079080687597518705556615437167362048.0
[...]

[Arcterus]

I'm assuming that they use GMP or something. Anyhow, I just fixed this using num-bigint and am currently cleaning up the code, so I'll likely push either later tonight or sometime tomorrow evening. I've also switched to using i64 instead of f64 when possible, so that'll hopefully make seq faster in the general case.

[jfinkels]

Fixed by pull request #2322 I think.

[tertsdiepraam]

Indeed, the issue is no longer present.