Hi Roger! On 1/10/19 8:04 AM, Roger Riggs wrote:
Hi,
If we're going to break some apps that use non-conforming strings, perhaps we should go fully strict and make sure they are all fixed at the same time. (Unless we have some stats on the distribution of non-conforming apps that mitigates that).
That's my point: While going fully strict may break some applications out there, rejecting only obviously incorrect input will likely affect only those applications with a bug. It can be thought as a first step toward full conformance to the RFC. For now, reject only the most incorrect inputs, and leave the final step, if desired, to JDK-8165199 <https://bugs.openjdk.java.net/browse/JDK-8165199>. With kind regards, Ivan
Roger
On 01/10/2019 02:27 AM, Ivan Gerasimov wrote:
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.ht...
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