Re: [xml] core dump buglet in libxml2 when setting new prop

[Thomas Broyer <tbroyer ltgt net>]

Thomas Broyer wrote: 
> > Since then, illegal expressions such as "75.2E-12" became legal in
> > libxml view and some expressions don't produce expected result anymore
> > (the above example is converted to the string "7.52e-11" whereas
> > "0.0000000000752" is expected)
> >
> > Any explaination about the why and the goal of such a transformation? 
>
> Very simple. XPath uses ANSI/IEEE Std 754 (1985) for floating point
> numbers. This standard uses a fixed numbers of digits (bits, actually) to
> represent numbers, which means that it cannot accurately represent, say,
> the number pi as it would require an infinite number of digits.

The XPath spec states (4.2 String Functions, string()) that a float should
be represented with "as many, but only as many, [] digits as are needed to
uniquely distinguish the number from all other IEEE 754 numeric values."

> It also means that big numbers cannot be represented accurately with the
> regular 9.9 floating point notation.

What's this notation?

> If we were going to try this, the least significant digit would be
> garbage.

See above.

Notice that the XPath spec also have a note saying that "the string
function is not intended for converting numbers into strings for
presentation to users." Thus, whether the output has some garbage isn't
really annoying.

> Anybody who disagrees are welcome to contribute a patch.

I'm feeling like Daniel and would prefer an extension function or at least
a flag (similar to SAX properties) to switch between XPath 1.0 and partial
XPath 2.0 conformance.

Tom.
P.S.: sorry for breaking threads, balsa crashed and I lost some mails, I
just cut&pasted from on-line archives.