From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-63089-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 16582 invoked by alias); 18 Apr 2009 11:05:48 -0000
Received: (qmail 16570 invoked by uid 22791); 18 Apr 2009 11:05:47 -0000
X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_73,J_CHICKENPOX_83,SPF_SOFTFAIL
X-Spam-Check-By: sourceware.org
Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 18 Apr 2009 11:05:40 +0000
Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KIA00900MOGED00@i-mtaout7.012.net.il> for gdb-patches@sources.redhat.com; Sat, 18 Apr 2009 14:05:37 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KIA00HXUMTCIJG0@i-mtaout7.012.net.il>; Sat, 18 Apr 2009 14:05:37 +0300 (IDT)
Date: Sat, 18 Apr 2009 11:05:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: Configuring gdb_wchar.h
In-reply-to: <m3iql7jiy6.fsf@fleche.redhat.com>
To: tromey@redhat.com
Cc: gdb-patches@sources.redhat.com
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83ljpyi5ml.fsf@gnu.org>
References: <8363hboz5x.fsf@gnu.org> <m3tz4smocb.fsf@fleche.redhat.com> <833acbo32k.fsf@gnu.org> <m3iql7jiy6.fsf@fleche.redhat.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2009-04/txt/msg00483.txt.bz2

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 10:31:13 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Tom> Please try the appended patch.
> 
> Eli> It compiles and links okay, thanks.  Do you want me to test some
> Eli> feature(s) to make sure the resulting binary works as expected?
> 
> Sure.  If you have dejagnu, try charset.exp.

I ran some of the tests in charset.exp by hand, and I see some
potential issues.

For example, when I set the host charset to UTF-8 and the target
charset to EBCDIC-US, I get an error message:

    Cannot convert between character sets `EBCDIC-US' and `UTF-8'

Is this expected?  Is this again a consequence of the list of charsets
not coming from libiconv, but from the default?

Also, this result seems to be different from what charsets.exp
expects:

    Breakpoint 1, main () at charset.c:173
    173        }
    (gdb) set host-charset ASCII
    (gdb) set target-charset ISO-8859-1
    (gdb) print iso_8859_1_string[69]
    $2 = -94 '\242'
    (gdb) print iso_8859_1_string+70
    $3 = 0xbdb6 "\21"
    (gdb) print iso_8859_1_string[70]
    $4 = 17 '\21'

Perhaps I misunderstood, but this part of the test seems to expect
something different, at least for the second and third print commands:

    # Test handling of characters in the target charset which
    # can't be translated into the host charset.
    if {! [string compare $target_charset iso-8859-1]} {
        gdb_test "print iso_8859_1_string\[69\]" \
                 " = \[0-9-\]+ '\\\\242'" \
                 "print character with no equivalent in host character set"
        gdb_test "print iso_8859_1_string + 70" \
                 " = ${hex} \"\\\\242.*\"" \
                 "print string with no equivalent in host character set"
    }

I also noticed that on a GNU/Linux system, "set target-charset TAB"
shows the list of possible charsets with a ^J character at the end of
each line.