[
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)
