This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Selectable execution character set (and a whole bunch of side effe
zack@codesourcery.com (Zack Weinberg) wrote on 07.07.03 in <87brw6l7se.fsf@egil.codesourcery.com>:
> kaih@khms.westfalen.de (Kai Henningsen) writes:
>
> > zack@codesourcery.com (Zack Weinberg) wrote on 04.07.03 in
> > <87fzllq1at.fsf@egil.codesourcery.com>:
> >
> >> * This goes a long way toward eliminating the problems with EBCDIC,
> >> and selectable input character sets will get the rest of it. EBCDIC
> >> hosts need to have an iconv() that understands the UTF-EBCDIC
> >> encoding. Unfortunately, GNU iconv - at least, the version that
> >> shipped with glibc 2.3.1 - doesn't. It should not be hard to
> >> implement. I have not removed MAP_CHARACTER from the back-end
> >> interface yet, only because this patch is too big already; it is now
> >> unused.
> >
> > Ugh.
> >
> > While there's nothing wrong with teaching iconv about UTF-EBCDIC, why on
> > earth would you want to *use* it?
>
> Because it does exactly what I need: it's isomorphic to Unicode (so
> there is no problem implementing \u escapes) and unibyte characters
> match EBCDIC code points (so I don't have to replace every last
> character constant in cpplib with a number, at great cost to
> readability).
Hmmm ...
It's certainly a bootstrapping problem.
However, wouldn't
char c = L'A';
work (in gcc) for getting 0x41 even with a local charset of EBCDIC?
(And would it be a serious problem to say you can only bootstrap gcc on
EBCDIC with a compiler where this is true - need a cross from ASCIIverse
otherwise?)
Or am I misunderstanding the problem?
MfG Kai