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 434557 - Improper schema validation on large integers
Improper schema validation on large integers
Status: RESOLVED NOTABUG
Product: libxml2
Classification: Platform
Component: general
2.6.27
Other All
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2007-04-30 10:45 UTC by Ueli Waldispuhl
Modified: 2008-05-08 05:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ueli Waldispuhl 2007-04-30 10:45:53 UTC
Please describe the problem:
Running a Windows binary of libxml2.
I have an xsd with an element as follows:
---------
  <xs:simpleType name="orderNrType">
    <xs:restriction base="xs:integer">
      <xs:totalDigits value="26"/>
    </xs:restriction>
  </xs:simpleType>
---------
When I validate against this with an xml like this
<orderNr>10000820070417000076000000</orderNr>
the validation fails.

I investigated the problem in 2 dimensions:
Varying the xml value: Up to a length of 24 digits the validation succeeds, above that it fails.
Increase of the totalDigits value: No effect.

I calculated that 24 decimal digits just fit into 80 bits. Presumably it's a matter of integer capacity.


Steps to reproduce:
1. Create an xsd defining an integer with totalDigits = 24 (or more).
2. Create an xml containing an integer with 25 decimal digits.
3. Validate


Actual results:
A validation error with a diagnostic like
Element '{http://www.swisscom.com/wsg/2007-03/WSGModel}orderNr': '1000082007041700007600000' is not a valid value of the atomic type '{http://www.swisscom.com/wsg/2007-03/WSGModel}orderNrType'.

Expected results:
XML file passing validation without error condition

Does this happen every time?
yes

Other information:
Comment 1 Ueli Waldispuhl 2007-04-30 10:48:38 UTC
"Steps to reproduce" has been entered incorrectly. It should say
1. Create an xsd defining an integer with totalDigits = 26 (or more).
(26 instead of 24)
Comment 2 Daniel Veillard 2007-05-02 15:49:38 UTC
http://www.w3.org/TR/xmlschema-2/#decimal

:Note:  All ·minimally conforming· processors ·must· support decimal numbers with :a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18). However, :·minimally conforming· processors ·may· set an application-defined limit on the :maximum number of decimal digits they are prepared to support, in which case that :application-defined maximum number ·must· be clearly documented.

http://www.w3.org/TR/xmlschema-2/#integer

is derived from decimal.
You cannot expect a conforming implementation to handle more than 18 digits
You are using 26, you're beyond the risk limit w.r.t. the spec, and libxml2
limit is 24

 Not a bug, fix your schemas or get different validator, but your XSD is not
portable.

Daniel
Comment 3 Matej Spiller-Muys 2008-05-08 05:39:01 UTC
FYI:
dup of mine report: http://bugzilla.gnome.org/show_bug.cgi?id=350248

From working draf http://www.w3.org/TR/xmlschema11-2/#conformance

When either of these is so, a conforming processor must indicate to the user and/or downstream application that it cannot process the input data with assured correctness (much as it would indicate if it ran out of memory). When the datatype validity of a value or literal is uncertain because it exceeds the capacity of a partial implementation, the literal or value must not be treated as invalid, and the unsupported value must not be quietly changed to a supported value.