Fix some unsafe reads.

[adam-vessey]

If they failed to read the number of bytes, the return of -1 would cause infinite loops, with -1 always less than the minimum offset of 0.

An alternative to #551 fixing #550, and more, touching on #551 (comment)

Did a bit of a grep around for similar broken patterns which should get a similar fix; though, there may be some others. In particular, suspicious of this bit of JPEG2000KakaduImageReader, but not terribly sure on the expectations around it, and don't use Kakadu.

[adam-vessey]

Test failures seem to be due to tests failing to pull in binaries to start the run? grok seems to have deleted all the releases prior to 12 from GitHub, and the tests are trying to pull 7.something.

And something off in the Windows build, it seems?

[La0]

Any idea why some unit tests are not passing here ?

Just saw your previous comment afterward, so it may be unrelated to your changes

[glenrobson]

I think when we merge in the changes in #656 or #653 we can update this branch and the tests should be fixed.

[glenrobson]

Cantaloupe dev call 3rd July.

Thanks changes look good and will look again once the library updates have been applied to develop.

[jcoyne]

@adam-vessey would you be able to rebase this on the develop branch? That should allow all the tests to pass. Then we can look at merging this.

[adam-vessey]

Taking a cursory look through the failing tests, generally seems to be testing failure conditions, expecting edu.illinois.library.cantaloupe.processor.SourceFormatException exception, but now it is returning java.io.EOFException. java.io.EOFException is similarly a java.io.IOException, so unsure how the methods here quite had an effect on this? As in, am expecting to see something on the wrapping around the reads to consistently rethrow/wrap java.io.IOExceptions as [...].SourceFormatExceptions given the test assertion, but not seeing where it is? Or, are the test assertions too specific?
Or yeah, should there be some try/catch wrapping? Probably in JPEG2000MetadataReader.readData() to catch the java.io.IOExceptions, to wrap with [...].SourceFormatException, with something in the message about image corruption?

---

As in, something like: adam-vessey/cantaloupe@fix/unsafe-reads...adam-vessey:cantaloupe:fix/wrapped-reads ?

Created a draft PR with it, to see what happens: #681

Seems to have done the trick over on #681 (not sure about whatever is happening with the linux/graalvm build; don't believe it's anything I did)

[DiegoPino]

@adam-vessey merged! dc7947a
Feel free to rebase. Thanks again

[adam-vessey]

@DiegoPino : Closing this one in favour of #681, given the JPEG2000 metadata reader tests would still fail here without the changes being made there, or changes of some other nature (reworking the tests to more generic exceptions?).