[OpenJDK 2D-Dev] [9] 8152293: Incomplete fraction reduction in getValueAsString() for TIFFTag.TIFF_RATIONAL, TIFFTag.TIFF_SRATIONAL

[Alexander Stepanov]

Hello, Brian

On 11/15/2016 7:25 PM, Brian Burkhalter wrote:
> Hello Alexander,
>
> On Nov 15, 2016, at 4:11 AM, Alexander Stepanov 
> <alexander.v.stepanov at oracle.com 
> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>
>> Thank you for the comments (hopefully I wasn't too confident picking 
>> the issue).
>
> You’re welcome. I doubt that you will have any trouble with it.
>
>> Yes, from the "do not harm" position it seems better to remove all 
>> the reduction-related fragments (leaving these worries to the user), 
>> but keep the zero denominator checks + the sign checks for the 
>> unsigned fractions.
>
> Again, as I mentioned, I don’t know about the feasibility of zero 
> denominator checks given that it is sometimes necessary to create a 
> TIFFField whose data object is allocated but uninitialized.
yes, the changes in createArrayForType() were made for this purpose. 
probably they are not enough..
>
>> One more silly question - if some upper bound (2^32 - 1) check should 
>> be added for TIFF_RATIONAL's numerator/denominator? At a 1st glance, 
>> it seems to be needless; on the other hand, it seems that the longs 
>> should be used to store 32-bit unsigned integers(?). Not sure if it 
>> could cause any side effects.
>
> If one were to do the actual division and the numerator is not a 
> multiple of the denominator, then the result would likely be stored as 
> a floating point value. Given that I am not sure that an overflow 
> check is needed.
>
> Thanks,
>
> Brian

Looking more carefully at some other TIFF_<TYPES>, some other potential 
border/sign issues can be seen (JDK-8169725, JDK-8169728). So it seems 
there is some common potential imprecision here.

Thanks,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20161115/12d56fce/attachment.html>