GNOME Bugzilla – Bug 320914
negative zero formatted incorrectly by format-number
Last modified: 2021-07-05 10:59:21 UTC
This is based on OASIS Microsoft test case XSLTFunctions__testOn-0.00. Here's
the output from libxml and Xalan
xsltproc testOn-0.xsl fmt-no.xml
java5 -cp /Users/elharo/Downloads/xalan-j_2_7_0/xalan.jar
org.apache.xalan.xslt.Process -IN fmt-no.xml -XSL testOn-0.xsl
libxml (and the expected test case output) may be correct here. Then again maybe
not. The question is really what format-number(round(-.5), '#,##0.00') should
return. However, this is tricky because it really depends normatively on what
Java 1.1 did, and off the top of my head I'm not sure about that. What did
return in Java 1.1? (Also, was it even possible to create negative 0 in Java
1.1? If so, how?)
See http://issues.apache.org/jira/browse/XALANJ-2226 for details and sample
documents. The OASIS test suite is wrong here (or so claim the Xalan
developers). That is, libxslt shoudl format this as -0.00, not 0.00.
Referencing the Java-1.1 behaviour for formatting was a serious mistake
in XSLT-1.0 ... I wonder is the principle of least surprize should not
be used there and check how they tried to correct this in XSLT-2.0, if this
behaviour is clearly documented in 2.0 then it might be a good idea to
follow that suggestion. It's probably more important to be compatible
with XSLT-2.0 than on the dead Java-1.1 behaviour, since this aspect is
fairly confusing. Do you know XSLT-2.0 behaviour there ?
Referencing the Java 1.1 behaviour for formatting was absolutely a mistake
in XSLT 1.0. That said, I still feel it's better to follow the spec even if XSLT
2 goes in a different direction. I'm not sure XSLT 2 does though. It's certainly
not clearly documented, though perhaps it can be inferred from the text of the
XSLT 2 spec by someone more nuanced than me. However XSLT 2 certainly doesn't
explicitly address the weird case of negative zero.
Okay, let's accept that as a NEW bug, it's probably relatively simple to
handle but I can't really do this right now.
Created attachment 55386 [details] [review]
no, that proposed fix won't do - it causes (+ve) zero values to be given a negative suffix/prefix. You
might want to pre-check any proposed enhancement by running "make tests" (either from the top-level
directory to check all test cases, or from the subdirectory tests/numbers to specifically test number
Comment on attachment 55386 [details] [review]
Changing status of my patch to "rejected".
Created attachment 55406 [details] [review]
Thanks for telling me about "make tests". Anyway, I should test before
uploading patches. Sorry for your time.
The patch signbit.diff should be better. I've now tested with "make tests" in
However, I'm not sure about the modification in "configure". I've added
-std=c99 to CFLAGS for gcc. Can this break things elsewhere? Must similar
compiler options be added for other compilers?
A more portable solution is to use xmlXPathGetSign from libxml2. This is a static function, though, and must be made public first.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).
If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at
Thank you for your understanding and your help.