Project

Profile

Help

Bug #4688

closed

EE 9.9.1.7 strange function parameter overriding

Added by Andy Yar over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XPath conformance
Sprint/Milestone:
-
Start date:
2020-08-17
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9, trunk
Fix Committed on Branch:
10, 9.9, trunk
Fixed in Maintenance Release:
Platforms:

Description

Hello, during an internal Saxon upgrade 9.8.0.15J to 9.9.1.7J regression testing we have found out a strange issue. Our custom functions suddenly started to behave odd.

Using following snippet, the output should mimic the standard format-number(). Thus it should format value1 and value2 using the mask given as second parameter of the function call. However, this doesn't seem to be the case using EE 9.9.1.7.

The whole transformation file is attached as test2.xsl.

 <xsl:template match="root">
        <root>
            <format1>
                <xsl:value-of select="f:format-number(value1, '000')"/>
            </format1>
            <format2>
                <xsl:value-of select="f:format-number(value2, '0000000000')"/>
            </format2>
        </root>
    </xsl:template>

...

The output contains both value1 and value2 formatted as both were using the second mask of the parameter call.

 <format1>0000000058</format1>
 <format2>0000000064</format2>

For example, using PE 9.9.1.7 seems to handle the parameter passing correctly:

  <format1>058</format1>
  <format2>0000000064</format2>

Since there are numerous differences in both Saxon configurations, both attached outputs (fail.xml and correct.xml) contain a full environment printout. These particular test outputs were obtained using a copy of Oxygen IDE.

Is this a known issue? Thanks


Files

fail.xml (8.27 KB) fail.xml Wrong output - format1 using not the first parameter 000 but the second one Andy Yar, 2020-08-17 16:17
correct.xml (8.26 KB) correct.xml Correct output - format1 using correct parameter 000 Andy Yar, 2020-08-17 16:17
format.xml (107 Bytes) format.xml Dummy test data Andy Yar, 2020-08-17 16:17
test2.xsl (2.52 KB) test2.xsl Two calls of a custom fuction Andy Yar, 2020-08-17 16:17
Actions #1

Updated by Michael Kay over 4 years ago

Thanks for reporting it.

It's something to do with function inlining - it goes away when you run with -opt:-f, which suppresses function inlining.

Actions #2

Updated by Michael Kay over 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Michael Kay

It also goes away when you run with -explain, which I don't think I've ever seen before!

Actions #3

Updated by Michael Kay over 4 years ago

Looks like this is essentially the same problem as bug #4549, but this time with the format-number() function rather than the key() function.

Actions #4

Updated by Michael Kay over 4 years ago

Fixed in the same way as for #4549: make FormatNumber implement StatefulSystemFunction, and give it a copy() method.

Actions #5

Updated by Michael Kay over 4 years ago

  • Category set to XPath conformance
  • Status changed from In Progress to Resolved
  • Applies to branch 10, 9.9, trunk added
  • Applies to branch deleted (9.7)
  • Fix Committed on Branch 10, 9.9, trunk added

Fix committed to 9.9, 10.x, and trunk.

Test case format-number-070 added to XSLT3 test suite.

Actions #6

Updated by Andy Yar over 4 years ago

I can confirm the -opt:-f works as a workaround. Many thanks

Actions #7

Updated by O'Neil Delpratt about 4 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.2 added

Bug fix applied in the Saxon 10.2 maintenance release.

Actions #8

Updated by Andy Yar about 4 years ago

Hello O'Neil Delpratt and Michael Kay,

Do you plan to release a maintenance release including this fix also for the 9.9.x branch?

Thank you!

Actions #9

Updated by Michael Kay about 4 years ago

We've been continuing to apply patches to the 9.9 branch for significant bugs, but we don't have any scheduled date for another maintenance release on that branch; it's usually triggered either by the number of outstanding bugs to be fixed, or by a customer situation where someone has a good reason for not moving forward, and no simple workaround is available.

Actions #10

Updated by O'Neil Delpratt about 4 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.9.1.8 added

Bug fix applied on the Saxon 9.9.1.8 maintenance release.

Please register to edit this issue

Also available in: Atom PDF