On 31/12/2022 02:02, наб wrote:
Package: coreutils
Version: 9.1-1
Severity: normal
Dear Maintainer,
We all know that for a 4-byte number the maximum value is 2^32-1,
and for an 8-byte one ‒ 2^64-1.
Even if we accept that for some bizzarre reason shuf
wants to be limited to 4-byte numbers,
then it should at least actually allow all of them.
Why, then:
-- >8 --
$ bc -q
2^32
4294967296
$ shuf -n1 -i 0-4294967296
shuf: invalid input range: ‘4294967296’: Value too large for defined data type
$ shuf -n1 -i 0-4294967295
shuf: invalid input range: ‘0-4294967295’
$ shuf -n1 -i 0-4294967294
2310362399
-- >8 --
and
-- >8 --
$ bc
2^64
18446744073709551616
$ shuf -n1 -i 0-18446744073709551616
shuf: invalid input range: ‘18446744073709551616’: Value too large for defined
data type
$ shuf -n1 -i 0-18446744073709551615
shuf: invalid input range: ‘0-18446744073709551615’
$ shuf -n1 -i 0-18446744073709551614
16168582199677063639
-- >8 --
I mean, to hell with the highlighted bit of the range being different,
or there being no error string, apparently, right,
but why can't you just generate an integer?
Why is the operational range apparently one smaller than [0, 0xFFFFFFFF]?
This is disproportionately worse on ILP32 platforms given #1027412;
if this were just one off the end of 2^64, eh, who cares.
We shrink the range by one to use as an internal flag.
Since the range is already limited, this isn't seen as a practical issue.
I.e. the same more detailed response in bug #1027412 applies here also.
cheers,
Pádraig
