Re: revised proposal for GCC and non-Ascii source files

[Paul Eggert <eggert at twinsun dot com>]

   Date: Tue, 29 Dec 1998 15:14:53 +0100
   From: Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>

   C++ tries '$', then '.', then '_'. Because the latter may give
   conflicts, we put __static_ in front of the entire identifier
   (i.e. __static_1F_u00C0).

OK, here's a revised version of the name Ascization part of that
proposal, which should be safe in the presence of C++ name mangling.
Sorry, it's a bit complicated, but I don't see a way to simplify it
without introducing other disadvantages.


 9. With -funify-names, identifiers (including their UCNs)
    are translated to UTF-8 internally; if the input ctype
    is not a subset of UTF-8, any extra information is lost, and if
    the input ctype is GNUC only UCNs are translated.  With
    -fno-unify-names, each UCN in identifiers is translated to the
    input ctype internally, if the corresponding character
    exists; otherwise, it is canonicalized by converting all its
    hexadecimal digits to upper case and by converting `\U0000XXXX' to
    `\uXXXX'.  Two identifiers are considered to be the same if and only
    if their internal representations are identical.

10. After the translation described in (9), assembler identifiers are
    output with escape bytes if necessary.  If an assembler identifier
    contains characters that are not allowed by the platform, the
    following steps are done (in order) before the identifier is
    output:

     . Each instance of the escape byte is doubled.  The escape byte
       is `.' if `.' and `$' are both allowed in identifiers, and is
       `V' otherwise.

     . The `\' of each UCN is replaced by the escape byte.
       This can occur only if -fno-unify-names is in effect, since
       -funify-names never puts UCNs into an internal identifier.

     . Each byte in a disallowed character is replaced by its 2-digit
       hexadecimal code in upper case, prefixed by the escape byte.

     . If the escape byte is `V', then `__9V_' is prepended to the
       entire identifier.

    Normally the bytes $.0-9A-Z_a-z Ascii are allowed in assembler
    identifiers, but some platforms prohibit `$' or `.', and some
    platforms allow any nonzero byte.

----------

For example, suppose

 . The input encoding is ISO 8859-1.
 . @ represents the character MICRO SIGN (Unicode `00B5', UTF-8 `C2 B5',
   ISO 8859-1 `B5').
 . # represents the character GEORGIAN CAPITAL LETTER AN (Unicode `10A0',
   UTF-8 `E1 81 A0', no ISO 8859-1 representation).

If -fno-unify-names is in effect, the identifier
`p@q\u00b5r\U000010a0sVt' is represented internally as
`p@q@r\u10A0sVt'; note that the internal @ uses a one-byte ISO 8859-1
representation.  If @ and \ are not allowed by the platform, the
identifier output is `p.B5q.B5r.u10A0sVt' if the escape character
is `.', and is `__9V_pVB5qVB5rVu10A0sVVt' otherwise.

If -funify-names is in effect, the same identifier is represented
internally as `p@q@r#sVt'; note that the internal @ and # use
multibyte UTF-8 representations.  If @ and # are not allowed by the
platform, the identifier output is `p.C2.B5q.C2.B5r.E1.81.A0sVt' if
the escape character is `.', and is
`__9V_pVC2VB5qVC2VB5rVE1V81VA0sVVt' otherwise.


----------

Properties of this proposal: ...

 D. With the GNUC ctype, or any UTF-8 ctype, -funify-names has no effect.

 E. The internal form of assembler identifiers can never contain a null
    byte, and therefore `.00' (or `V00' if the escape byte is `V') can
    never appear in an assembler identifier.

----------

Rationale ...

R10b. Why does the escape convention for outputting identifiers in Ascii
      depend on whether the assembler allows `$' in identifiers?

      C++ name mangling uses `$' if available, otherwise `.' if
      available, otherwise `_' (prepending `__static_' to the entire
      identifier).  If `$' not available but `.' is available, then
      identifier Ascization must not use `.', as that would clash with
      C++ name mangling.  If `$' and `.' are both available, it is
      safe for Ascization to use `.', since C++ name mangling uses `$'
      in that case.  It is preferable to use `.' if it is available,
      since that avoids any possible clashes with user identifiers.