After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 320914 - negative zero formatted incorrectly by format-number
negative zero formatted incorrectly by format-number
Status: RESOLVED OBSOLETE
Product: libxslt
Classification: Platform
Component: general
unspecified
Other All
: Normal minor
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2005-11-07 21:26 UTC by elharo
Modified: 2021-07-05 10:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
minus-zero.diff (589 bytes, patch)
2005-11-29 19:22 UTC, Bart Martens
rejected Details | Review
signbit.diff (992 bytes, patch)
2005-11-30 09:04 UTC, Bart Martens
none Details | Review

Description elharo 2005-11-07 21:26:05 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.
Comment 1 Daniel Veillard 2005-11-07 22:05:54 UTC
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
Comment 2 elharo 2005-11-07 22:29:47 UTC
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. 
Comment 3 Daniel Veillard 2005-11-07 22:49:13 UTC
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
Comment 4 Bart Martens 2005-11-29 19:22:51 UTC
Created attachment 55386 [details] [review]
minus-zero.diff
Comment 5 William M. Brack 2005-11-30 00:16:05 UTC
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 6 Bart Martens 2005-11-30 08:46:15 UTC
Comment on attachment 55386 [details] [review]
minus-zero.diff

Changing status of my patch to "rejected".
Comment 7 Bart Martens 2005-11-30 09:04:15 UTC
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?
Comment 8 Nick Wellnhofer 2016-04-30 17:40:18 UTC
A more portable solution is to use xmlXPathGetSign from libxml2. This is a static function, though, and must be made public first.
Comment 9 GNOME Infrastructure Team 2021-07-05 10:59:21 UTC
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.