This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support
- From: Daniel Jacobowitz <drow at false dot org>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Julian Brown <julian at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Sun, 1 Feb 2009 13:23:44 -0500
- Subject: Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support
- References: <20090115202411.5f154657@rex.config> <m37i4dx64p.fsf@fleche.redhat.com> <20090130194343.GA3964@adacore.com> <m3ocxos6og.fsf@fleche.redhat.com>
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