https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039

--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
> > (In reply to Rainer Orth from comment #0)
> >> 
> >> The problem obviously is that the native assemblers don't support UTF-8 in
> >> identifiers (and I bet there are other non-gas assemblers that don't 
> >> either).
> >> 
> >
> > Do we have a function that checks if the effective target supports utf-8 in
> > assembler?
> 
> we do: there's ucn, used in some of the gcc.dg/ucnid-*.c tests.
> 
> However, there's another option: C11, 6.4.2.1 General, n.71 suggests
> 
> On systems in which linkers cannot accept extended characters, an
> encoding of the universal character name may be used in forming valid
> external identifiers. For example, some otherwise unused character or
> sequence of characters may be used to encode the \u in a universal
> character name.  Extended characters may produce a long external
> identifier
> 
> (cited from the n1570.pdf draft).  Go, which heavily relies on UTF-8
> identifiers, does something like this:
> cf. gcc/go/gofrontend/go-encode-id.{cc,h}.
> 

The following comment echoes the current thoughts on UTF-8 support in
identifiers.

```
When I originally started with D, I thought non-ASCII identifiers with Unicode
was a good idea. I've since slowly become less and less enthusiastic about it.

First off, D source text simply must (and does) fully support Unicode in
comments, characters, and string literals. That's not an issue.

But identifiers? I haven't seen hardly any use of non-ascii identifiers in C,
C++, or D. In fact, I've seen zero use of it outside of test cases. I don't see
much point in expanding the support of it. If people use such identifiers, the
result would most likely be annoyance rather than illumination when people who
don't know that language have to work on the code.
```

I'm not sure given them an encoded mangle in similar vain to Go would be a
desirable direction, so better off relegating the tests.

Reply via email to