#1027100 coreutils: wc: total overflows unchecked

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
наб
Date:
2023-03-29 19:21:02 UTC
Severity:
normal
#1027100#5
Date:
2022-12-27 19:31:48 UTC
From:
To:
Dear Maintainer,
#1027100#10
Date:
2022-12-28 13:38:00 UTC
From:
To:
It's a good point.
We might just output ERR or NAN or something
in place of a total value in the overflow case.
We should also do the same in df --total

cheers,
Pádraig
#1027100#15
Date:
2022-12-28 13:38:00 UTC
From:
To:
It's a good point.
We might just output ERR or NAN or something
in place of a total value in the overflow case.
We should also do the same in df --total

cheers,
Pádraig
#1027100#20
Date:
2022-12-28 14:05:36 UTC
From:
To:
Hi!

Given that you can't process that file as anything other than
regular-file-optimised wc -c, and it's a really pathological input,
I'd say just doing a saturating addition for the total is fine.

Funnily enough, I did torture-test df this morning, and the same happens
there. Admittedly, I'd say that's really not an issue, since you'd need
to actually have an absurd amount of filesystems, with a nominal total
of over 16E.

The only realistic scenario I can imagine here is, like, a 2P ZFS pool
with >8096 descendant filesystems; it sounds pathological, and it kind of
is, but I did get there, and if you go to a slightly larger pool you get
vaguely within the order of magnitude of the realm of what some workloads
are seeing, if you have ZFS configured as a docker backend, for example;
but then --total is also completely meaningless in that case; I'd classify
this as a purely theoretical scenario not worth more code than maybe
just saturating the addition if you have an easy-to-use primitive.

Best,
наб