[jira] [Resolved] (DAFFODIL-1044) DPath not finding obvious type errors involving constants at compile time

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

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

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

Fixed in commit a2f56a3f44d307a138fb7a4614f873120e186d63

> DPath not finding obvious type errors involving constants at compile time
> -------------------------------------------------------------------------
>
>                 Key: DAFFODIL-1044
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1044
>             Project: Daffodil
>          Issue Type: Bug
>          Components: DFDL Language, Middle "End"
>    Affects Versions: s15
>            Reporter: Michael Beckerle
>            Assignee: Steve Lawrence
>            Priority: Major
>             Fix For: 2.3.0
>
>
> See test test_expression_type_error2()
> The test has an expression which clearly is erroneous. 
> {code}
> <xs:element name="e3" type="xs:int" dfdl:inputValueCalc="{ 2.5 }" />
> {code}
> where a decimal/floating point constant is given as the value for an xs:int type element. 
> Current behavior just truncates and produces the value 2.
> This is the right semantics for the xs:int(...) function call. 
> This from the XPath functions spec: 
> If ST is xs:decimal, xs:float or xs:double, then TV is SV with the fractional part discarded and the value converted to xs:integer. Thus, casting 3.1456 returns 3 and -17.89 returns -17. Casting 3.124E1 returns 31. If SV is too large to be accommodated as an integer, (see [XML Schema Part 2: Datatypes Second Edition] for ��implementation-defined�� limits on numeric values) an error is raised [err:FOCA0003]. If SV is one of the special xs:float or xs:double values NaN, INF, or -INF, an error is raised [err:FOCA0002].
> Right now, if a value is returned by an expression via inputValueCalc, then it is converted to the type of the element in exactly the same way that an argument to a function is converted.
> This leads to the strange anomalies like  test_expression_type_error2() where there is a clear mistake by the schema author.
> Fixing this so we can issue an SDE or warning requires that the DPath constant folding be enhanced substantially so that it can not only determine if an entire expression is a constant or not, but sub-expressions within an expression.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)