Re: NO_DOLLAR_IN_LABEL

[Paul Eggert <eggert at twinsun dot com>]

   Date: Wed, 06 Jan 1999 00:05:46 -0800
   From: Per Bothner <bothner@cygnus.com>

   > Does the phrase ``the character's numeric value'' assume that native
   > extended characters are translated to Unicode before mangling begins?

   For Java, they have to be.  For C and C++, I think that is the
   cleanest solution.

I tend to agree, and that's why my proposal has a -funify-names option.

RMS prefers that names be left as-is by default, though, so the
proposal also has a -fno-unify-names option.  I think the default
value of this option will depend on the platform, and that
Java-oriented platforms will prefer -funify-names.

   This is what is going to happen for Java, so we will have to
   be able to translate external encodings into UTF8 on input, and vice
   versa on output (in gdb and in ld/as error messages).  So there is
   no simplification in leaving external characters untranslated

These are good points, but I think your conclusion is too strong.  I
can think of at least one simplification: with -fno-unify-names, a
non-Java GCC installation won't need translation tables to and from
UTF-8.  This is a simplification, since these translation tables are a
maintenance hassle: they are not available on all platforms, and I
doubt whether it's wise to include the tables in GCC itself.  (Even
maintaining Ebcdic-to-Ascii tables is dicey, but just try maintaining
tables translating private JIS extensions to UTF-8!)

In other words, if -fno-unify-names is in effect, the non-Java part of
GCC will be easier to port to non-UTF-8 environments; this is a plus.