13796 2011-08-16 19:24:35 +0000 [Applet30] \u escaped characters in grammar applets 2016-04-27 20:36:52 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Grammar Test Applets Working drafts PC Windows XP RESOLVED FIXED P2 normal --- 1 andrew.eisenberg jmdyck jim.melton mike public-qt-comments oldest_to_newest 55244 0 andrew.eisenberg 2011-08-16 19:24:35 +0000 When I parse the expression '\u0045' I see the following: |START [1:0 - 1:8] | QueryList [1:0 - 1:8] | Module [1:0 - 1:8] | MainModule [1:0 - 1:8] | Prolog [1:0 - 0:0] | QueryBody [1:0 - 1:8] | Expr [1:0 - 1:8] | StringLiteral 'E' [2:1 - 1:8] I expected: | StringLiteral '\u0045' [2:1 - 1:8] 55258 1 jmdyck 2011-08-17 03:29:57 +0000 The conversion of unicode escapes (\uHHHH) is happening in code that JavaCC generates. The odd thing is, we're explicitly telling JavaCC (via the JAVA_UNICODE_ESCAPE option) to generate that code. We've done so since 2005/03/25. It looks like this came about from confusion/conflation with the UNICODE_INPUT option (which controls whether the input stream object reads "Unicode files" or ASCII files). 55303 2 jmdyck 2011-08-17 15:14:15 +0000 Unfortunately, simply disabling the option causes some tests to fail, so this will take some investigation. 57482 3 andrew.eisenberg 2011-09-28 18:18:19 +0000 This issue came to my attention due to test cases in our QT3 test suite. I've reported the bug there as Bug #14328. 125874 4 josh.spiegel 2016-04-15 20:39:32 +0000 *** Bug 29568 has been marked as a duplicate of this bug. *** 126220 5 jmdyck 2016-04-27 20:36:52 +0000 I tried disabling the JAVA_UNICODE_ESCAPE option again today, and (to my surprise) the test-failures mentioned in comment #2 no longer occurred. I'm surprised because the version of JavaCC I'm using hasn't changed since I wrote comment #2. However, the versions of Java and Ant that I'm using *have* changed, so perhaps the bug lay somewhere in there. Anyhow, the applets now deliver the result that Andrew expected originally, so I'm marking this bug resolved-fixed.