On Sun, Feb 16, 2014 at 07:53:33PM -0500, James Cloos wrote: > >>>>> "RB" == Ran Benita <[email protected]> writes: > > RB> But the grammar in the parser and the implementation say: > RB> ESCAPED_CHAR ::= ('\\' | '\"' | OCTAL | HEX ) > RB> HEX ::= '\' (x|X) HEX_CHAR [HEX_CHAR]] > RB> HEX_CHAR ::= (0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|a|b|c|d|e|f) > > Given that the original code was written for eight-bit encodings, I > suppose that is not surprising that the grammar is only cabable of > octal and hex octets. > > I presume a different parser must be used for the XLC_LOCALE files, > as those have longer hex escapes (also using \x).
Yes, that's a different parser. I haven't looked closely at the XLC_LOCALE files, they seem scary and should be largely irrelevant for modern systems, no? > Should we fix the doc or update the parser to handle larger hex? I don't think so, currently it's just simple C-like char <-> escape correspondence. And I'd hope there won't be any more non-UTF-8 multiple-bytes encoding that we need to support in the future. > And on that front, should we add a \u escape to insert the utf-8 for > a given code point? If the file is UTF-8 already, I think it makes more sense to just write the string directly, without escaping it. But if you think this makes sense I can try to add it. Ran > -JimC > -- > James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
