Four string literals carry the bytes A3 A5, which is GBK for U+FF05, the
fullwidth percent sign. All four sit in g_lang == i18n::Lang::zh branches
added by "Chinese specific update (by zww from tbs)", and each has an ASCII
sibling in the else branch using an ordinary percent.
clang-cl decodes source as UTF-8, where A3 is not a valid lead byte:
error: illegal character encoding in string literal
A raw high byte in a literal means whatever the compiler's source charset
says it means, so this text has never been portable. Asking the cl we build
with what it makes of L"%d%<A3><A5>%%" gives a 7-character string whose
fourth character is 163 -- it reads the bytes as Latin-1 and produces two
characters, £ and ¥, not the one the author wrote. The same probe on
L"%d%％%%" gives 6 characters with U+FF05 in that position.
So the Chinese text has been rendering as garbage in any build not made on a
CP936 machine, this one included. Writing the character as ％ says
exactly which character is meant regardless of the compiler's charset, and
restores what the branch was written to display.
The format grammar is untouched. In each of these strings the character is
preceded by a percent, making %<fullwidth percent> an unknown conversion
specification that prints the character following it -- the same trick the
else branches spell as %%. Where a string is formatted twice, once into a
buffer and again as the format argument of mprintf, the doubling in the
sibling literal (%%%%) is what survives two passes; that pairing is
unchanged.
Both files are now pure ASCII:
python3 -c "print(sum(1 for b in open(F,'rb').read() if b>0x7f))"
The parse sweep drops from 5 error sites in 3 files to 1 in 1 -- the inline
assembly in sgp/vobject_blitters.cpp is all that is left.
Marco Antonio J. Costaandmajcosta
8495af4b00