Project

Profile

Help

Bug #4537

closed

Overzealous static analysis?

Added by Norman Tovey-Walsh almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2020-05-01
Due date:
% Done:

100%

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

Description

If you process the attached stylesheet against any input, it will report:

Warning at char 32 in xsl:sequence/@select on line 43 column 70 of units.xsl:
  SXWN9000  Evaluation will always throw a dynamic error: Cannot convert string "1.0in" to double

It then goes on to succeed because the evaluation isn't actually trying to convert "1.0in" to a double, it's trying to convert "1.0" to a double.


Files

driver.xsl (675 Bytes) driver.xsl Norman Tovey-Walsh, 2020-05-01 22:45
units.xsl (2.91 KB) units.xsl Norman Tovey-Walsh, 2020-05-01 22:45
Actions #1

Updated by Michael Kay almost 4 years ago

Just to summarise what's happening, as a result of constant folding and function inlining, we get to

<xsl:when test="matches($length, $vp:percent-regex)">
      <xsl:variable name="perc"
                    select="replace($length, $vp:percent-regex, '$1')"/>
      <xsl:sequence
          select="$nominal-page-width * xs:double($perc) div 100.0"/>

and during type-checking, we are able to establish that xs:double($perc) will never succeed; however this branch of the xsl:when will never be taken, so the warning is spurious.

As it happens, in this particular case, we know statically that this branch of the xsl:choose will never be taken, so we ought to be able to be a bit smarter. Of course, it could also happen that we don't know this, in which case we probably shouldn't try to be so smart.

It's tricky to know how best to handle this. In general, if early evaluation of constant expressions (during the type-checking or optimization phases) throws a dynamic error then we report this warning, and I'm reluctant to abandon this as a general principal. But we should probably be a bit smarter when we're in a branch of a conditional, especially if we already know that the condition will be false.

Actions #2

Updated by Michael Kay almost 4 years ago

  • Status changed from New to Resolved
  • Applies to branch 9.9 added
  • Fix Committed on Branch 10 added

On the 10.0 branch I have changed Choose.typeCheck() and Choose.optimize() to do nothing for branches that won't be executed (these branches will be eliminated immediately after type-checking / optimization anyway).

In the interests of stability, I'm going to leave the code as is on the 9.9 branch.

Actions #3

Updated by O'Neil Delpratt almost 4 years ago

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

Bug fix committed in the Saxon 10.1 maintenance release.

Actions #4

Updated by O'Neil Delpratt almost 4 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF