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

[Richard Stallman <rms at gnu dot org>]

    > Wouldn't it work for GCC to treat all byte values above 127 as part of
    > an identifier, and not worry about how they group into multibyte
    > characters?

    That would work fine. It might or might not be what the user expects.

Passing along the multibyte sequence unchanged is the most natural
thing to do; it is what cat does, for example.  Why would any user be
surprised by it?

    The only real drawback is standards compliance. C++, Java, and C9X all
    allow to express Unicode in identifiers using \u escapes, like

    void h\u00D6llo();

You are right 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.

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?

    Of course, the easiest thing would be to assume that we always get
    non-ASCII in identifiers as Unicode escapes. 

No, just the opposite.  If the non-ASCII characters are represented in
multibyte, then GCC can handle them properly in a locale-independent
way.  But \u cannot be handled in a locale-independent way.
Therefore, Emacs should save these characters in multibyte
representation (which, as it happens, is the more general feature, and
what we are going to work on anyway).