[xml/sgml-pkgs] Bug#247465: xsltproc: Incorrect result due to computations in extended precision

[Vincent Lefevre]

Package: xsltproc
Version: 1.1.5-1
Severity: normal

I'm reporting a new bug since bug 206549 is archived.

Consider the following ieee754-xpath.xsl stylesheet:

------------------------------------------------------------------
<?xml version="1.0"?>

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="text" indent="no"/>

<xsl:template match="/">
  <xsl:choose>
    <xsl:when test="9007199254740992 + 1.00001 = 9007199254740992">
      <xsl:text>Not a conforming XPath implementation.</xsl:text>
    </xsl:when>
    <xsl:otherwise>
      <xsl:text>OK</xsl:text>
    </xsl:otherwise>
  </xsl:choose>
  <xsl:text>&#10;</xsl:text>
</xsl:template>

</xsl:stylesheet>
------------------------------------------------------------------

On x86, it gives:

greux:~/wd/xsl> xsltproc ieee754-xpath.xsl ieee754-xpath.xsl
Not a conforming XPath implementation.

This is due to computations in extended precision internally.

Note that this problem is specific to Linux/x86 and the way the
library has been compiled in Debian. On FreeBSD and NetBSD machines
(and I've been told that this is the same under MS-Windows), the x86
processor is configured to compute in double precision, so that this
problem doesn't occur.

There are several ways to fix that:

  1) The library could be compiled using -msse2 -mfpmath=sse to use
     SSE2 instructions, but these instructions are present only in
     recent processors (e.g. Pentium 4). I don't know if they can be
     emulated on non-SSE2 processors...

  2) The internal FP precision could be temporarily changed to double
     precision each time a FP computation is performed in the library.

  3) The internal FP precision could be changed to double precision at
     the beginning of xsltproc, and any program using libxslt should do
     the same (this should be documented), but this could be difficult
     when using libxslt from Perl, for instance.

  4) Have the Linux kernel changed so that double precision is always
     used by default? (This could break badly written Linux/x86-only
     programs.)

Concerning 2 and 3, the problem is that changing the FP precision
isn't portable, and the glibc doesn't implement fegetprec / fesetprec
(see bug 237373); so, the /usr/include/fpu_control.h macros should be
used in these cases. That would probably be OK in Debian, I suppose.

I reported the problem upstream[*] but any patch would not be portable
(the bug was closed as WONTFIX, but Daniel Veillard would accept a
portable enough patch).

[*] http://bugzilla.gnome.org/show_bug.cgi?id=123297

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1

Versions of packages xsltproc depends on:
ii  libc6                       2.3.2.ds1-12 GNU C Library: Shared libraries an
ii  libxml2                     2.6.9-2      GNOME XML library
ii  libxslt1.1                  1.1.5-1      XSLT processing library - runtime 
ii  zlib1g                      1:1.2.1-5    compression library - runtime

-- no debconf information