This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
cbcl-numeric-idivide-008 (in test set op-numeric-integer-divide) tests: xs:float('1e38') idiv xs:float('1e-37') The test expects the overflow error FOAR0002, but it seems that FOCA0002 should also be allowed (raised when trying to convert infinity to an integer). Alternatively an implementation may return a large integer as the result.
A little more rationale on this: The spec of idiv (via op:numeric-integer-divide) says it returns "the largest integer such that...." so in principle an implementation that supports 75-digit integers ought to be able to deliver a successful result. However, the specification also allows the implementation to choose a different algorithm that might have failure conditions if limits are exceeded, and it is not prescriptive about what error codes might arise in this case. Saxon is using the perfectly reasonable algorithm of doing an xs:float division and then rounding down to an integer. In this case the xs:float division produces INF and the rounding then fails. For what it's worth, I've experimented with a different algorithm and it produces 999999976930990075686379158893828419930518285429571090543203585326070980319, but I suspect other approaches might deliver a slightly different but equally valid result.
I've added FOCA0002 and a large integer (1 x 10^75). Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN.
I have further modified the "success" result to <any-of> <error code="FOAR0002"/> <error code="FOCA0002"/> <all-of> <assert-type>xs:integer</assert-type> <assert>matches(string($result), '^[0-9]{75,76}$')</assert> </all-of> </any-of> since I think rounding errors are acceptable (given that we allow the implementation a wide choice of algorithms). For example if you promote both floats to doubles, do the division, and then round to an integer, you won't get exactly 10^75.