Hi Joe!
From what I see, the discussion was about possibility to only accept
input strings with precisely sized parts, i.e. that matches
"\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}-
\p{XDigit}{12}".
And I'm proposing to only reject input with too large individual parts,
i.e. accept any input that matches
" \p{XDigit}{1,8}- \p{XDigit}{1,4}- \p{XDigit}{1,4}- \p{XDigit}{1,4}-
\p{XDigit}{1,12}".
Currently, if one part is too large, we already "clip" it, using only
lower bits, so behavior looks buggy.
Instead, it seems better to report the issue throwing an exception.
With kind regards,
Ivan
On 1/9/19 11:08 PM, Joe Darcy wrote:
Hi Ivan,
How does this bug relate to the recent discussion of "JDK-8165199:
UUID.fromString(str) compliance checking?":
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html
Cheers,
-Joe
On 1/9/2019 3:23 PM, Ivan Gerasimov wrote:
Hello!
String representation of UUID should conform to RFC4122
<https://tools.ietf.org/html/rfc4122>, i.e. each its part has to be
of the fixed size.
Unfortunately, the UUID.fromString() method does not keep up to this
requirement:
- First, it permits the leading zeroes of any part to be omitted;
- Second, it permits some of the UUID parts to be larger then
allowed. In such a case, the value is effectively clipped with &
0x..FFFF.
While some existing application may depend on the former case -- i.e.
be able to parse UUID with stripped leading zeroes, the later case is
likely to be an error.
In the past, the check on the input has already been strengthened
with JDK-8006627 <https://bugs.openjdk.java.net/browse/JDK-8006627>.
I propose we go further and make UUID.fromString() to reject such
string representations that contain too large individual parts.
If people agree on the proposal, I'll file CSR to fix the change of
behavior.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216407
WEBREV: http://cr.openjdk.java.net/~igerasim/8216407/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
