[metif12]

truncate: stop comparing a correct size with an overflowed one

size is a u64 and V's int is 32 bits, so the three large sizes in test_size_parser
were wrapped before the comparison ever happened:

assert s.size == 24 * 1000 * 1000 * 1000
  Left value     24000000000
  Right value    -1769803776

The implementation was right and the expectation was wrong, so this is three
literals written out and a note saying why:

-24GB   24 * 1000 * 1000 * 1000              ->  24_000_000_000
/14PB   14 * 1000 * 1000 * 1000 * 1000 * 1000 -> 14_000_000_000_000_000
%1E     1 * 1024 * 1024 * 1024 * 1024 * 1024 * 1024 -> 1_152_921_504_606_846_976

V has no 24u64 literal to fix this at the type, which is why the values are
spelled out.

Tests

src/truncate is 1 of 1 against uutils 0.0.17 and v fmt -verify src/truncate
passes. Nothing outside the test file changed.

[JalonSolov]

Conflicts.

[metif12]

Closing this one: #196 already fixed it, differently.

This PR changes the size assertions in truncate_test.v so a large size is spelled out rather than multiplied, e.g. 24_000_000_000 instead of 24 * 1000 * 1000 * 1000, because the literal multiplication overflows. But main carries this instead:

assert s.size == u64(24) * 1000 * 1000 * 1000

from 475101a (#196), "repair the 10 test files that were failing for unrelated reasons". Casting to u64 before the multiplications avoids the same overflow, so the assertion this PR was written to add is already there. Rebasing would leave the PR with nothing to change.

The four conflicting hunks were all of this shape, and none of them were mechanical text conflicts — both sides asserted the same value and both were correct, so picking a side would have been arbitrary.

[metif12]

Superseded by #196, which fixed the same overflow by casting to u64 first. Closing rather than force-pushing an empty PR.