For our purposes, I am going to patch xpath.c(patch attached if you're interested) to preserve the parsing logic validating that the string conforms to the same grammar. The patch removes all the numeric computation from the validation and instead calls atof on the validated string for the conversion to a double. While the original problem I emailed about involved numbers that were not compliant with XPath 1.0, we found another example which I believe conforms to XPath 1.0 and returns an unexpected result. The follow XPath returns false and I expect it to return true (2.7.2 on 64-bit Linux): <xsl:value-of select=".30000000000004 = '.30000000000004'"/> After applying my patch, it now returns true which would be the expected behaviour. It also fixes the non-standard compliant example I provided in my original email. Cheers, Chris. ----- "Bjoern Hoehrmann" <derhoermi gmx net> wrote:
* Christopher R. Palmer wrote:/** * xmlXPathStringEvalNumber: * @str: A string to scan * * [30a] Float ::= Number ('e' Digits?)?Is that [30a] from some addendum to XPath 1.0 or is it a libxmlextension? It would have to be an extension, new features cannot be added to W3C recommendations without re-issuing the recommendation, which in case of XPath 1.0 has not happened so far. Also, the "Errata" does not in- clude http://www.w3.org/1999/11/REC-xpath-19991116-errata/ it. It seems http://mail.gnome.org/archives/xml/2001-April/msg00080.html has some background on this. -- BjÃrn HÃhrmann  mailto:bjoern hoehrmann de  http://bjoern.hoehrmann.de Am Badedeich 7  Telefon: +49(0)160/4415681  http://www.bjoernsworld.de 25899 DagebÃll  PGP Pub. KeyID: 0xA4357E78  http://www.websitedev.de/
Attachment:
libxml2-atof-2.7.3.patch
Description: Binary data