Repair sometimes tries to read beyond EOF

[jcfp]

As the title says. I stumbled upon this by coincidence, when I intentionally damaged a file (as part of a test) by truncating it and subsequently trying to have par2 repair it. Happens with 0.6.6 as well as with older versions, 0.4 included, with multiple files and on multiple systems.

Probably also the cause of this old bug report in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415984

To reproduce (starting from an empty dir...):
"""
wget -O test.data https://github.com/BlackIkeEagle/par2cmdline/archive/rel-0-1.zip
par2 c -r10 test.par2 test.data
mv test.data test.data-correct
head -c 113579 test.data-correct > test.data
par2 r test.par2
"""

The repair process will error out:
"Could not read 60 bytes from ./test.data.1 at offset 113520"

Note that (in this example) truncating one byte more or one byte less results in a correct repair. Badness also happens when truncating the test.data to 115259, 116519, 116339 at least.

The following script tries to find the troublesome truncations by brute forcing:
(note: not very fast...; the default settings should be good for use with the test.data supplied above)
See https://gist.github.com/jcfp/f9de277f3610fa842f0f

[BlackIkeEagle]

from what i see par2 was not made to cope with broken files who have a different filesize than the original.

i think i can fix it anyway but have to make sure nothing else breaks