Community
Participate
Working Groups
Presently, type promotion does not function, e.g. in expressions like "1 div 0.0" which is performed as an integer division, not a floating point one. While the subtype substitution rules appear to work, the way the oprator functions are called through reflection (on the left hand object) makes it hard to handle promotion properly. I have a patch for this which I will attach once M1 is done - it is blocking some of the other tests, such as fn-substring-10 which uses this cleverly: fn:substring("12345", -42, 1 div 0E0)
Created attachment 143858 [details] Adds type promotion for float and double operations This patch corrects the problem found with missing type promotion on operators. It fixes the test op-numeric-integer-divide-1 which has has its test expectancy changed in a previous revison (idiv should raise FOAR0002 (overflow), not FOAR0001 (div-by-zero) when an argument is NaN). The patch also fixes this behaviour. In addition, three substring tests now also pass: test_fn_substring_7(org.eclipse.wst.xml.xpath2.processor.testsuite.functions.SubstringFuncTest) test_fn_substring_8(org.eclipse.wst.xml.xpath2.processor.testsuite.functions.SubstringFuncTest) test_fn_substring_11(org.eclipse.wst.xml.xpath2.processor.testsuite.functions.SubstringFuncTest)
As for the promised effect on fn-substring-10, it will be fixed when the surrogates patch (bug 282096) is applied...
(In reply to comment #2) > As for the promised effect on fn-substring-10, it will be fixed when the > surrogates patch (bug 282096) is applied... (In reply to comment #1) > Created an attachment (id=143858) [details] > Adds type promotion for float and double operations > > This patch corrects the problem found with missing type promotion on operators. > > It fixes the test op-numeric-integer-divide-1 which has has its test expectancy > changed in a previous revison (idiv should raise FOAR0002 (overflow), not > FOAR0001 (div-by-zero) when an argument is NaN). > > The patch also fixes this behaviour. > In addition, three substring tests now also pass: > > test_fn_substring_7(org.eclipse.wst.xml.xpath2.processor.testsuite.functions.SubstringFuncTest) > test_fn_substring_8(org.eclipse.wst.xml.xpath2.processor.testsuite.functions.SubstringFuncTest) > test_fn_substring_11(org.eclipse.wst.xml.xpath2.processor.testsuite.functions.SubstringFuncTest) > Ha...I knew I had the substring code corrected, just couldn't figure out how to get it to correctly get the expected error values. Thanks. I'll work on this along with your other patches sometime Friday since Wednesday/Thursday is the M1 milestone for 3.2M2. I have a blog entry coming on the work you have done as well ask Mukul.
targetting for 3.2m2
Patch applied to head. Thanks I was wondering how we were going to fix this.
Well, isn't the normalizer intended for this sort of thing?
(In reply to comment #6) > Well, isn't the normalizer intended for this sort of thing? > They could be, more information on Normalization, which actually needs it's own bug report opened, can be found on the XPath/XQuery Semantics page: http://www.w3.org/TR/xquery-semantics/#sec_normalization Basically there are a set of rules for the mapping to a normalized form.
