Eric Blake wrote: > Consider the original filename of `dir??/file'. Before my patch, the > c_quoting_style converted it to `"dir?\?/file"', since `??/' is a trigraph > for `\', but that is not a valid C string. Right now, the output is > `"dir?""?/file"', i.e. two concatenated C strings, so that a C parser > would unambiguously recognize the quoted output, even if it is parsing > trigraphs.
Sorry, but you lost me here. Where did the C trigraphs come into play? You started by pointing out an ambiguity in error message output. The desire was to define a variant syntax that would be 1. possible to parse unambiguously, 2. still understandable to a human user. And now you are talking about C trigraphs, this invention whose only purpose is to write C in a character set that lacks brackets, braces, backslash and similar characters? And that are not understood by 99.9% of the human users? > For C strings, the code already outputs \a, \b, \f, \n, \r, \t, \v, \\, > \"; and for all other non-printable characters, a 3-digit \nnn octal So you want to escape, in an UTF-8 locale, all non-ASCII characters or bytes? So that a Japanese user, for an error in file をつけた時でも, gets to read \343\202\222\343\201\244\343\201\221\343\201\237\346\231\202\343\201\247\343\202\202 ? This is far, far away from the original goal, and also neglects the principle of minimal surprise. I mean, if the goal is to solve ambiguities, then please add enough escapes to solve ambiguities, but not more than that! Bruno
