Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support

[Tom Tromey <tromey@redhat.com>]

>>>>> "Julian" == Julian Brown <julian@codesourcery.com> writes:

Tom> Perhaps we can invoke "iconv -l" at startup... eww.

Julian> I ran into this problem too. An earlier version of my patch
Julian> had this, in register_iconv_charsets():
[...]
Julian> ...which isn't quite right, but can maybe be adapted into something
Julian> which is.

Nice.

GNU libiconv has the iconvlist function... I wish this were portable.

I suppose we could try that, then popen(iconv -l), and then fall back
to some built-in list.

Tom> Another difference is that I have the intermediate step go through the
Tom> host wchar_t rather than UCS-4.  This is nice because it means we can
Tom> use iswprint to decide if something is printable.  But, it may have
Tom> limitations, I suppose, on a host where wchar_t is less capable.

Julian> I think that might break for recent win32, where wchar_t is
Julian> UTF-16 (i.e.  more than one wide character may be needed for a
Julian> given code point).

I think my current code ought to work ok in this case, assuming that
w32's iswprint returns false for surrogate characters.  In this case
we'll just emit escape codes.

This area is still not ideal, though.  In particular, my current code
only works on hosts that define __STDC_ISO_10646__.  Does w32 define
this?

Hmm, I just thought of a way we can perhaps do better.  I will look at
this a little more.

Tom