Re: [RFC] Make string printing work on NetBSD (iconv issue)

[Tom Tromey <tromey@redhat.com>]

>>>>> "Paul" == Paul Koning <Paul_Koning@Dell.com> writes:

Paul> It clearly can't make matters worse, because any platform that doesn't
Paul> have the codeset name "wchar_t" currently doesn't work at all. 

I think it is worse in one sense, which is that the results can be
incorrect with no warning.  In particular I believe this could happen on
Solaris in some locales.

I do see your point though.  Completely failing is terrible.

Paul> NetBSD clearly is using UCS-4 for wchar_t, but it does not define that
Paul> symbol.

Bummer.

Yet another idea would be host-specific overrides for INTERMEDIATE_ENCODING.

Tom> Alternatively, it is always safe to fall back to the code that uses
Tom> narrow intermediate characters and host_charset for the intermediate
Tom> encoding.

Paul> Yes, but doesn't that mean you end up not being able to accurately print
Paul> a wide string if one occurs in your program -- because it gets mapped to
Paul> the intermediate encoding first and with narrow chars for intermediate
Paul> coding you have a lossy translation?

Nope, there is code in gdb to handle this.  You will see escape
sequences for any unprintable or untranslatable characters.  The only
problem is just that more characters are considered to be unprintable in
this scenario; roughly speaking this gets you back to what gdb 6.8 would
do.

Tom> Other approaches are available too, but they are generally more work
Tom> than simply using GNU libiconv.

Paul> Right, if you use libiconv then the issue goes away, and the patch I
Paul> wrote should handle that case cleanly.  I wanted to offer a solution to
Paul> people who don't want to install libiconv because they have a functional
Paul> iconv in libc, as is the case for NetBSD.

Another possible approach is to choose a known intermediate
representation, say UTF-32.  Then, provide gdb-specific replacements for
the various wide functions that are needed: wcslen, iswprint, iswdigit,
btowc.

Tom