This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: thoughts on martin's proposed patch for GCC and UTF-8
> I'm talking about the execution character set. E.g. printf ("\u00b5")
> should output a single byte in the Solaris 7 "de" locale, which uses
> ISO 8859/1.
Is this what you want to happen, or what some standard mandates to
happen? If so, what does the standard mandate for printf("\u1234");
> char hello[]="Hall\u00f6chen";
>
> you would get "Hall\303\266chen" at run time.
>
> That's certainly not true in draft C9x, for non-UTF-8 locales.
I didn't mean that C++ mandates that. It is implementation defined
what happens, and I'm proposing that egcs defines it that way.
> In draft C9x, if you want "Hall\303\266chen" at run time,
> you can write "Hall\303\266chen" at compile time.
You've confused input and output here. The question is not how to
achieve a certain output, but how to process a certain input.
> I also suspect that it's not true for C++. It's hard for me to
> believe that C++ requires UTF-8 encoding for strings at run-time.
It doesn't. It doesn't prohibit that, either.
> But your example above with `char hello' doesn't copy the bytes
> unmodified! It translates the 6 chars "\u00f6" to 2 bytes in your
> locale's charset and encoding, which is the right thing to do
No, it is not *my* locale, it is how gcc is (or could be) defined.
The big difference is predictability. If gcc defines that translation
into multibyte characters always means UTF-8 for \u escapes, people
know what to expect.
If the output *at run time* depends on the setting of environment
variables *at compile time*, people will kill us.
> If we get a \u escape (which the standard says clearly identifies
> ISO 10646 characters) we should also copy it as-is to the output.
>
> Again, you seem to be contradicting your own example.
Converting Unicode to UTF-8 is as close as you can get to 'as-is', if
you want to convert arbitrary Unicode to multibyte.
> Java is a different animal here; it requires Unicode at run-time. But
> we're talking about C (and C++), which make no such requirement.
We also plan to combine C++ and Java.
>
> WCHAR DriverName[] = "\u1234\u5678";
[...]
> Microsoft says you should use Unicode in certain situations.
>
> Absolutely. In a locale that uses Unicode, you should get Unicode.
Microsoft says you should get Unicode no matter what the locale is.
> Converting Unicode escapes to an encoding that uses illegal
> ASCII in assembler doesn't sound too smart to me.
>
> Sorry, you've lost me. ``illegal ASCII'??
Well, ASCII sequences that are not legal as identifiers.
> You're proposing that assembler files use UTF-8 in some cases, and the
> locale's multibyte encoding in other cases. Such files can't be
> processed by standard text tools.
I don't want to process assembler files by standard text tools, I want
the assembler to process it.
Martin