This is the mail archive of the
mailing list for the GCC project.
Re: gcc/libcpp: non-UTF-8 source or execution encodings?
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 19 Jul 2016 12:24:31 -0400
- Subject: Re: gcc/libcpp: non-UTF-8 source or execution encodings?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On Tue, Jul 19, 2016 at 12:05 PM, David Malcolm <email@example.com> wrote:
> libcpp/charset.c has a helpful introductory comment describingcharacter
> sets, including the source and execution character sets.
> libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for the
> source character set, via:
> #if HOST_CHARSET == HOST_CHARSET_ASCII
> #define SOURCE_CHARSET "UTF-8"
> #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0x7e
> #elif HOST_CHARSET == HOST_CHARSET_EBCDIC
> #define SOURCE_CHARSET "UTF-EBCDIC"
> #define LAST_POSSIBLY_BASIC_SOURCE_CHAR 0xFF
> #error "Unrecognized basic host character set"
> though libiberty's safe-ctype.c has:
> # if HOST_CHARSET == HOST_CHARSET_EBCDIC
> #error "FIXME: write tables for EBCDIC"
> so presumably we only effectively support UTF-8 as the source char set.
> Do we support any hosts for which the source character set is *not* UTF
> Similarly, do we support any targets for which the execution character
> set is *not* UTF-8?
> This relates to the locations-within-string-literals patch I posted
> ("[PATCH] RFC: On-demand locations within string-literals"); that patch
> currently has an assumption that the source encoding == execution
> encoding, and I'd appreciate knowing a configuration for which this
> isn't the case so I can test accordingly.
I believe that the GCC z/TPF configuration uses EBCDIC. There also is
the on-again off-again i370 port.