JDK-8254073, unicode escape preprocessing, and \u005C
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Jun 23 15:10:34 UTC 2021
How about -Xlint:unicode ... default on.
-- Jon
On 6/22/21 7:33 PM, John Rose wrote:
> It would be good if javac gave a warning when fed
> highly questionable puzzlers like the sequence of
> code points \ u 0 0 5 C. There’s no excuse for using
> it, and although the JLS tolerates it, it is almost
> certainly a mark of someone confusing themselves,
> or trying to confuse others.
>
> The deepest problems are with the unicode escape
> for the character (005C) which introduces the
> unicode escape. But I would also welcome a wider
> warning, which would report any use of a unicode
> escape which decodes to a legitimate token constituent
> in the basic ASCII set.
>
> For safety’s sake, I would want to warn on any printable
> (non-control) code point between 0020 and 007E inclusive,
> plus line terminators 000A and 000D.
>
> Such warnings would help train users away from
> writing obfuscated code, even if they thought they
> had a reason to do so, and it would also help users
> detect maliciously obfuscated code.
>
> Supposedly it’s useful to (once in a blue moon)
> re-encode everything in Java source file using
> unicode escapes (maybe for blank-free URLs?)
> but in such cases the warnings can be disabled
> and disregarded. Apart from blue moons,
> nobody ever, ever wants to get confused by
> unicode escapes which make a program less
> readable.
>
> — John
>
>> On Jun 21, 2021, at 2:56 PM, Jim Laskey <james.laskey at oracle.com> wrote:
>>
>> "\u005C” should have been treated as a backslash. Will check into it.
>>
>> Cheers,
>>
>> — Jim
>>
>>
>>
>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon <cushon at google.com> wrote:
>>>
>>>
>>> class T {
>>> public static void main(String[] args) {
>>> System.err.println("\u005C\\u005D");
>>> }
>>> }
>>>
>>> Before JDK-8254073, this prints `\]`.
>>>
>>> After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate?
>>>
>>> JLS 3.3 says
>>>
>>>> for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape.
>>> The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape.
>>>
>>> Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them?
>>>
>>> JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape.
>>>
>>> Thanks,
>>> Liam
More information about the compiler-dev
mailing list