Re: thoughts on martin's proposed patch for GCC and UTF-8

[Per Bothner <bothner at cygnus dot com>]

> (2) GCC uses the iconv function to translate from the input multibyte
>    encoding to UTF-8 internally (for identifiers

and strings in Java.

> (3) GCC transliterates each \u escape in a string to the string's charset,
>     which is specified as described in (1) above.

Hm.  (1) above specifies the *file's* charset.  It does not follow
that the *string's* charset is the same.  Certainly for Java, it
would not be.

What happens to:
	wchar_t x = '\u1234';  /* or:  L'\u1234' */
are these different from:
	wchar_t x = (wchar_t) 0x1234;

I assume your proposal is that the string charset at least
by default should be the file charset except for Java where
the string charset is Unicode.  I don't know if that is
reasonable;  I guess so.

> If the input character set is a superset of UTF-8
> (e.g. ISO-2022-JP), then the extra information is lost.

I'm confused.  I thought that Unicode was specifically designed
so that dictinct characters in existing Japanese character
standards were mapped into distinct Unicode characters.
Did I misunderstand, or is ISO-2022-JP not one of the "source"
character sets the Unicode designers used?

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner