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 ~/projects/xom/data/oasis-xslt-testsuite/tests/MSFT_Conformance_Tests/XSLTFunctions$ xsltproc testOn-0.xsl fmt-no.xml <DIV>0.00</DIV> ~/projects/xom/data/oasis-xslt-testsuite/tests/MSFT_Conformance_Tests/XSLTFunctions$ 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 <DIV>-0.00</DIV> 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 (new DecimalFormat("#,##0.00")).format(-0.0) 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 ? Daniel
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. thanks ! Daniel
Created attachment 55386 [details] [review] minus-zero.diff
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 formatting) Bill
Comment on attachment 55386 [details] [review] minus-zero.diff Changing status of my patch to "rejected".
Created attachment 55406 [details] [review] signbit.diff 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 tests/numbers. 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxslt/-/issues/ Thank you for your understanding and your help.