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

[Daniel Jacobowitz <drow@false.org>]

On Sun, Feb 01, 2009 at 03:40:29PM -0700, Tom Tromey wrote:
> Daniel> It seems like a dummy version of iconv_open which only succeeds if the
> Daniel> two character sets are the same, plus a pass-through version of iconv,
> Daniel> would be enough to remove the iconv dependency.  That degraded mode
> Daniel> covers all local debugging.
> 
> The wchar_t issue comes into play because we actually do two
> conversions when printing: one from the target charset to the host
> wchar_t, and then a second one from the host wchar_t to the host
> "narrow" charset.
> 
> This just adds a wrinkle to the implementation, though -- the general
> plan still applies.  We could either pretend that wchar_t == char, or
> we could make an iconv that uses the mb* functions.

I see.  Yes, this will be a bit trickier, but not much.

As far as portability goes, we may have to experiment.  But I can tell
you flat out that swprintf is going to be a problem; it's a C99
library function and most hosts don't have C99 library extensions.

I see that gnulib has at least part of a vasnwprintf implementation...
I wonder if they're planning to finish it.

> I can implement this, but I'd rather do it only if it is truly needed.
> 
> How are you planning to handle this for Code Sourcery?  Really I would
> like to hear the answer to this from anybody shipping a gdb
> executable.

We're really not the ones you have to convince.  This is a
difficulty-building-GDB issue; commercial distributors only have to
get it to build once.  And we tend to be limited to mainstream
platforms; e.g. 95% of the toolchains CodeSourcery builds are
hosted on either Windows (mingw32) or GNU/Linux (RH8, RHEL3).
We've used a static GNU libiconv for our Windows tools for ages.

People on HP/UX or AIX may have a more interesting time of it.

> Daniel> There'd need to be a little additional
> Daniel> logic too, to allow you to set all the charset variables at
> Daniel> once
> 
> I think "set charset" already does this.  It doesn't handle the target
> wide charset, but that seems ok in the degraded functionality mode.

Right.  Except that if the wide charset remains unchanged, validate
will report an error since it can't convert to it...

-- 
Daniel Jacobowitz
CodeSourcery