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

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jan 30, 2009 at 04:41:35PM -0700, Tom Tromey wrote:
> Joel> Do you think we could have a configure option that allows us to
> Joel> deactivate this feature in order to avoid the dependency?
> 
> I don't think it would be very easy to make this an optional feature,
> or to make it fall back to the currently existing code.
> 
> I suppose one option would be to have a degraded mode where we require
> that the host charset and the target charset be the same.  Then maybe
> we could make it work by redefining iswprint and wchar_t.

I don't see the connection between the iconv dependency and iswprint /
wchar_t.  Are there portability issues for those too?  They don't come
from libiconv.

It seems like a dummy version of iconv_open which only succeeds if the
two character sets are the same, plus a pass-through version of iconv,
would be enough to remove the iconv dependency.  That degraded mode
covers all local debugging.  There'd need to be a little additional
logic too, to allow you to set all the charset variables at once;
otherwise you'd be stuck since validate would fail when you tried to
change any of them.  Or just remove the settings in that case.

> I don't think it would be very easy to preserve the current
> functionality and make the iconv stuff an add-on.  The current charset
> API is not well suited to variable length encodings.

In my opinion, the current non-iconv, non-identity conversions
are not a major loss.  But if someone was motivated to preserve them,
it seems like that wouldn't be hard; add them to the fallback
implementation of iconv.

-- 
Daniel Jacobowitz
CodeSourcery