User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101
Firefox/115.0
Build Identifier: 

Running "wipe" on a 1.81 TiB disk, it shows negative percentages after moving
on from "0%". This suggests that the calculations for the progress information
are made with an unsuitable numeric type, overflows are not detected and wipe
is not ready for large files and devices.

Furthermore, running to "-5%" and then checking how much data of the 1.81 was
overwritten, shows that it's not just a flipped sign as the absolute value
moves faster than expected, completing a percentage point equivalent to 18.4
GiB in a few seconds even though the target device's write speed in only about
110 MiB/s at best.

Reproducible: Always

Steps to Reproduce:
1. create or select large file or device that can be overwritten and deleted
for testing (my tests: 1995527224832 bytes and 2000395780096 bytes)
2. run "wipe" on the file (I added -D to keep the file for inspection)
3. observe progress information for a minute
4. ctrl-c at -7%
5. repeat wipe with "-z"
6. ctrl-c at -5%
7. run "hexdump -C myfileordevice | head" to see how much data was zeroed
Actual Results:  
/dev/bcache2: -2%

Only 10.1 GiB, i.e. 0.5% of the 1.81 TiB device, were zeroed when "-5%" was
displayed by "wipe".

Expected Results:  
Percentage in range 0 to 100.

For the 1.81 TiB device, between 83.4 GiB (4.5%) and 111.2 GiB (6%) should be
zeroed if the displayed percentage just has the wrong sign.

Likely, wipe cannot handle modern day file and device sizes properly as
indicated by open issues on https://sourceforge.net/p/wipe/bugs/ and 
https://bugzilla.opensuse.org/show_bug.cgi?id=1117493