Repository navigation
[IMAGING-386] TiffField numeric getters throw ImagingException for non-number values - #560
Open
sharanggupta wants to merge 1 commit into
Open
sharanggupta wants to merge 1 commit into
sharanggupta wants to merge 1 commit into
Conversation
…n-number values TiffField.getIntValue() cast the field value to Number without checking it. A BYTE field whose count is not 1 holds a byte[], so a malformed TIFF that declares FillOrder that way made Imaging.getBufferedImage() fail with a ClassCastException instead of the documented ImagingException. Check the type once in a private getNumberValue() and use it from getIntValue(), getLongValue() and getDoubleValue(), which had the same unchecked cast. The null check and the returned values are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes IMAGING-386.
What
TiffField.getIntValue()returned((Number) o).intValue(). For a field whose type is BYTE and whose count is not 1,FieldTypeByte.getValuereturns abyte[], so the cast threw aClassCastException, although the method documents@throws ImagingException if the value is missing or cannot be converted. The ticket's TIFF declares its FillOrder tag (a single SHORT in the specification) as BYTE with count 0, andAbstractImageDataReader.decompressreads that tag before any codec runs, soImaging.getBufferedImageescaped with aClassCastExceptioninstead of the documentedImagingException. The sibling methodsgetIntArrayValue,getIntValueOrArraySumandgetLongArrayValuealready turn an unsupported value into anImagingException.How
A private
getNumberValue()does the existing null check and now also rejects a value that is not aNumberwith anImagingExceptionthat names the tag and the actual value type.getIntValue()uses it.getLongValue()andgetDoubleValue()had the identical unchecked cast and the same Javadoc, so they use it too; I kept them in this change because it is the same defect and the same three lines, but I can split them out if you prefer. A normal numeric value returns exactly what it did before.Tests
TiffFieldTest:getIntValue,getLongValueandgetDoubleValuethrowImagingExceptionfor a BYTE field with count 0; a numeric field still returns its value (control).TiffFieldTest.testGetBufferedImageWithNonNumericFillOrder: the 438-byte file attached to the ticket (added asimages/tiff/IMAGING-386/crash-46f4...tif) now gives anImagingExceptionfromImaging.getBufferedImage.Without the change 4 of the 5 tests fail with
ClassCastException; with it all 1264 tests pass. Verified locally with the defaultmvngoal on Java 17 (RAT, Checkstyle, SpotBugs, PMD, Javadoc) and the test suite on Java 8. This PR is independent of #559 (IMAGING-385); the two touch different classes.Before you push a pull request, review this list:
mvn; that'smvnon the command line by itself.