Re: [xslt] XPath number formatting

[Tim Van Holder <tim vanholder anubex com>]

William M. Brack wrote:
> There has been a recent bug report
> (http://bugzilla.gnome.org/show_bug.cgi?id=337565) concerning the formatting
> of numbers by libxslt (actually by libxml2's xpath.c).  After reading through
> the XPath spec, it appears to me that this report is probably correct. 
> However, before I implement a "fix", I would like to give list members a
> chance to voice any potential disagreement.
> 
> The essence of the problem is this:  According to the spec, when a number is
> converted to a string (Section 4.2 String Functions),
> 
>    "if the number is an integer, the number is represented in decimal
>    form as a Number with no decimal point and no leading zeros,
>    preceded by a minus sign (-) if the number is negative"
> 
> However, there doesn't seem to be any good definition of what an "integer" is.
>  In particular, should a number which is greater than MAX_INT on some system
> still be treated as an "integer"?  The existing code within our library
> doesn't do this - instead, it treats it as a "non-integer" and outputs the
> value in exponential form.  I believe this is incorrect, but would welcome any
> opposing views.

Failing any specific mentions of programming languages or system
libraries in the spec, I would think that things like MAX_INT are
irrelevant.  I would assume that "integer" has the mathematical
meaning.  Even (modern versions) of COBOL can work with integers
that don't fit in MAX_INT (32 digits or more).

The only "problem" I see is that this may mean that libxslt needs
to start using GMP (or some other "BigNum" library); if it currently
treats, say, a 20-digit integer as a non-integer for stringizing
purposes, it seems likely that it won't handle it correctly in numeric
expressions either.