[
https://issues.apache.org/jira/browse/XERCESC-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guichard Desrosiers updated XERCESC-2263:
-----------------------------------------
Description:
SUMMARY
-------
NaN silently passes minInclusive and maxInclusive facet validation on xs:double
and xs:float types.
This is a regression caused by a mismatch between compareValues return domain
and boundsCheck
handling logic.
ROOT CAUSE
----------
compareValues was updated at some point to return 2 (INDETERMINATE) for NaN
comparisons instead
of 1. The boundsCheck logic in minInclusive and maxInclusive was never updated
to account for
this 4th return value, breaking the assumed trichotomy of \{-1, 0, 1}.
compareValues return values:
-1 → less than
0 → equal
1 → greater than
2 → INDETERMINATE (NaN)
Buggy checks:
minInclusive: if (result == -1) → FAIL misses INDETERMINATE(2) → NaN passes
✗
maxInclusive: if (result == 1) → FAIL misses INDETERMINATE(2) → NaN passes
✗
UNAFFECTED FACETS
-----------------
minExclusive and maxExclusive are not affected as their inverted logic
incidentally catches
INDETERMINATE(2):
minExclusive: if (result != 1) → FAIL catches -1, 0, and 2 ✓
maxExclusive: if (result != -1) → FAIL catches 0, 1, and 2 ✓
AFFECTED FACETS
---------------
xs:minInclusive on xs:double and xs:float
xs:maxInclusive on xs:double and xs:float
FIX
—
Tighten acceptance condition to only pass on known-valid orderings:
minInclusive: reject if (result != 1 && result != 0)
maxInclusive: reject if (result != -1 && result != 0)
*{*}PR:{*}* [fix: NaN bypasses minInclusive/maxInclusive facets by
gdesrosiers1805 · Pull Request #64 ·
apache/xerces-c|https://github.com/apache/xerces-c/pull/64]
was:
SUMMARY
-------
NaN silently passes minInclusive and maxInclusive facet validation on xs:double
and xs:float types.
This is a regression caused by a mismatch between compareValues return domain
and boundsCheck
handling logic.
ROOT CAUSE
----------
compareValues was updated at some point to return 2 (INDETERMINATE) for NaN
comparisons instead
of 1. The boundsCheck logic in minInclusive and maxInclusive was never updated
to account for
this 4th return value, breaking the assumed trichotomy of \{-1, 0, 1}.
compareValues return values:
-1 → less than
0 → equal
1 → greater than
2 → INDETERMINATE (NaN)
Buggy checks:
minInclusive: if (result == -1) → FAIL misses INDETERMINATE(2) → NaN passes
✗
maxInclusive: if (result == 1) → FAIL misses INDETERMINATE(2) → NaN passes
✗
UNAFFECTED FACETS
-----------------
minExclusive and maxExclusive are not affected as their inverted logic
incidentally catches
INDETERMINATE(2):
minExclusive: if (result != 1) → FAIL catches -1, 0, and 2 ✓
maxExclusive: if (result != -1) → FAIL catches 0, 1, and 2 ✓
AFFECTED FACETS
---------------
xs:minInclusive on xs:double and xs:float
xs:maxInclusive on xs:double and xs:float
FIX
—
Tighten acceptance condition to only pass on known-valid orderings:
minInclusive: reject if (result != 1 && result != 0)
maxInclusive: reject if (result != -1 && result != 0)
**Pull Request:** [PR64]([fix: NaN bypasses minInclusive/maxInclusive facets by
gdesrosiers1805 · Pull Request #64 ·
apache/xerces-c|https://github.com/apache/xerces-c/pull/64])
> NaN bypasses minInclusive/maxInclusive bounds check via unhandled
> compareValues INDETERMINATE(2) result
> -------------------------------------------------------------------------------------------------------
>
> Key: XERCESC-2263
> URL: https://issues.apache.org/jira/browse/XERCESC-2263
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (XML Schema)
> Reporter: Guichard Desrosiers
> Priority: Major
>
> SUMMARY
> -------
> NaN silently passes minInclusive and maxInclusive facet validation on
> xs:double and xs:float types.
> This is a regression caused by a mismatch between compareValues return domain
> and boundsCheck
> handling logic.
> ROOT CAUSE
> ----------
> compareValues was updated at some point to return 2 (INDETERMINATE) for NaN
> comparisons instead
> of 1. The boundsCheck logic in minInclusive and maxInclusive was never
> updated to account for
> this 4th return value, breaking the assumed trichotomy of \{-1, 0, 1}.
> compareValues return values:
> -1 → less than
> 0 → equal
> 1 → greater than
> 2 → INDETERMINATE (NaN)
> Buggy checks:
> minInclusive: if (result == -1) → FAIL misses INDETERMINATE(2) → NaN
> passes ✗
> maxInclusive: if (result == 1) → FAIL misses INDETERMINATE(2) → NaN
> passes ✗
> UNAFFECTED FACETS
> -----------------
> minExclusive and maxExclusive are not affected as their inverted logic
> incidentally catches
> INDETERMINATE(2):
> minExclusive: if (result != 1) → FAIL catches -1, 0, and 2 ✓
> maxExclusive: if (result != -1) → FAIL catches 0, 1, and 2 ✓
> AFFECTED FACETS
> ---------------
> xs:minInclusive on xs:double and xs:float
> xs:maxInclusive on xs:double and xs:float
> FIX
> —
> Tighten acceptance condition to only pass on known-valid orderings:
> minInclusive: reject if (result != 1 && result != 0)
> maxInclusive: reject if (result != -1 && result != 0)
>
> *{*}PR:{*}* [fix: NaN bypasses minInclusive/maxInclusive facets by
> gdesrosiers1805 · Pull Request #64 ·
> apache/xerces-c|https://github.com/apache/xerces-c/pull/64]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
