[jira] [Resolved] (DAFFODIL-3072) Float/double -0.0 leads to incorrect validation errors with daffodil validation

["Steve Lawrence (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Lawrence resolved DAFFODIL-3072.
--------------------------------------
    Resolution: Fixed

Fixed in commit f9be445a2bae8c82aa8435e5155a4d5a450ca822

> Float/double -0.0 leads to incorrect validation errors with daffodil validation
> -------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-3072
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-3072
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End
>    Affects Versions: 4.1.0
>            Reporter: Steve Lawrence
>            Assignee: Steve Lawrence
>            Priority: Major
>             Fix For: 4.2.0
>
>
> This schema outputs a validation error:
> {code:xml}
>   <element name="foo" dfdl:inputValueCalc="{ -0.0 }">
>     <simpleType>
>       <restriction base="xs:float">
>         <minInclusive value="0.0" />
>       </restriction>
>     </simpleType>
>   </element>
> {code}
> But according to XSD, -0.0 and 0.0 should be treated the same and should not create a validation error. Using the "xerces" validation mode has the correct behavior.
> This is likely a problem with both xs:float and xs:double types since they allow negative 0.0.
> The issue seems to be that RuntimeData uses the Float/Double compareTo function to check if a value is within the restriction range. But the compareTo function views -0.0 as less than 0.0. This behavior is different that what XSD expects, where -0.0 and 0.0 should be equivalent.
> The compareTo function also has special logic for NaN, so that probably does not handle NaN correctly either--a value of NaN should fail all restrictions.
> We probably should just use comparison operators (e.g. <, <=, >=, >).
> We should also inspect all of our other uses of compareTo to make sure they are doing the right thing, and considering -0.0 the same as 0.0 where appropriate. Those might also a similar fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)