RFR 8230365 : Pattern for a control-char matches non-control characters

[Stuart Marks]

Hi Ivan,

This change certainly makes regex patterns more rigorous, but I'm concerned 
about the compatibility. This is a spec change and also a behavior change. While 
the current behavior might not strictly be correct, it does have some 
characteristics that applications might be depending on -- perhaps even by 
accident. If this change is made, it might cause subtle issues in applications 
that would be quite difficult to diagnose.

Examples of changes I'm concerned about are:

pattern \ca currently matches '!' would now match \u0001
pattern \cÀ currently matches \u0080 would now throw exception
pattern \c0 currently matches 'p' would now throw exception

and so forth. That is, using \c with characters in the range [a-z] would now 
match different characters from before, and using \c with characters outside the 
set that correspond to C0 control characters would now throw an exception 
whereas before they would matching something that was predictable, if in some 
sense incorrect.

There are some ways to mitigate the incompatibility, for example, by adding a 
system property, or by adding a Pattern flag that explicitly enables this 
behavior, though I'm not sure that either is worthwhile. Maybe there are less 
intrusive ways that I haven't thought of.

The current behavior seems to be have been established around 1999 (JDK 1.3?) so 
it's been around a long time, plenty of time for applications to have formed 
inadvertent dependencies on this behavior. An alternative would be simply to 
document the current behavior, even though it's arguably incorrect.

Is there some benefit to this change, for example, does it enable one to write 
an application that wasn't possible before because of this bug?

s'marks


On 8/29/19 4:39 PM, Ivan Gerasimov wrote:
> Hello!
> 
> In a regular expression pattern a sequence of the form \\cx is allowed to 
> specify a control character that corresponds to the name char x.
> 
> Current implementation has a few issues with that:
> 1)  It allows x to be just any character, including non-printable ones;
> 2)  The produced regexp may correspond to a non-control characters;
> 3)  The expression is case-sensitive, so, for example \\cA differs from \\ca, 
> while they both have to produce ctrl-A.
> 
> It is proposed to make parsing more strict and reject invalid values of x, and 
> also clarify the documentation to explicitly list valid values of x.
> 
> If we agree on this proposal, then a CSR will probably need to be filed to 
> capture the changes in the regexp parsing.
> 
> Would you please help review the fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230365
> WEBREV: http://cr.openjdk.java.net/~igerasim/8230365/00/webrev/
>