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

[Paul Eggert <eggert@twinsun.com>]

   Date: Mon, 14 Dec 1998 03:22:51 -0700 (MST)
   From: Richard Stallman <rms@gnu.org>

   It remains desirable to make GCC handle multibyte input in a way that
   is independent of the locale--is there any *specific* problem with that?

Yes.  Some widely used multibyte encodings use ordinary ASCII bytes to
encode multibyte characters.  Examples include Shift-JIS, BIG5, and
7-bit ISO-2022.  The ASCII bytes include printable bytes like "\", so
this is an issue for both strings and identifiers.

These encodings all use first bytes that cannot be confused with any
of the single-byte chars in the basic C character set, so they can be
supported by a C compiler.

   Passing along the multibyte sequence unchanged is the most natural
   thing to do

Yes, I tend to think this is the right thing to do in both identifiers
and strings.  Otherwise, the assembly language output might not be a
text file, as it might use different encodings in different regions
with no easy way to distinguish between the reasons.

   that the handling of \u would have to depend on the multibyte
   representation, and therefore on the locale.  That would be
   unfortunate, but at least it would happen only when \u is used.

If GCC is to support encodings like Shift-JIS, it also needs to have a
locale-dependent way to determine the number of bytes in a multibyte
character.  It should copy these bytes straight through; but without a
way of being able to count them, it can't copy them.