From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20042 invoked by alias); 24 Apr 2003 20:26:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20035 invoked from network); 24 Apr 2003 20:26:17 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 24 Apr 2003 20:26:17 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EBD2D2B2F; Thu, 24 Apr 2003 16:26:14 -0400 (EDT) Message-ID: <3EA84866.9040702@redhat.com> Date: Thu, 24 Apr 2003 20:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: Eli Zaretskii , ezannoni@redhat.com, gdb@sources.redhat.com Subject: Re: charset.c problem with non-en_US locales References: <16037.41011.517603.566953@localhost.redhat.com> <7826-Wed23Apr2003124156+0300-eliz@elta.co.il> <3EA6ED61.1000900@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00302.txt.bz2 > Andrew Cagney writes: > >> Hmm, >> >> (gdb) set charset >> >> doesn't work. If that was fixed (using GDB's enum cli method), the >> command would become case sensitive. Since GDB's CLI is case >> sensative in general that would make sense. > > > Actually, the CLI is inconsistent: > > zenia:jimb$ gdb > GNU gdb 2003-04-17-cvs > Copyright 2003 Free Software Foundation, Inc. > ... > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". > (gdb) print 0 > $1 = 0 > (gdb) PRINT 0 > $2 = 0 > (gdb) PrInT 0 > $3 = 0 > (gdb) Dig, dig. Ulgh! That was added as part of the HP merge ..., part of xdb compatibility? As best I can tell, prior to Dec '98, GDB was strictly case sensative. It's now kind of both: - does a case sensative compare (typically already lowercase against lowercase, so pretty imune to i18n) - does a tolower compare I think there is sufficient case sensatitivity left in GDB for the common user (me? :-) to just assume it is so. Looking at charsets, it has a lowercase table ("iso-8859-1") where as the system (and ISO) specify upper case names (GDB_DEFAULT_TARGET_CHARSET "ISO-8859-1") causing the failure. > It seems to me that: > - cli-decode.c should use safe-charset.h, > - the enum code in cli-setshow.c should be changed to be > case-insensitive, using safe-charset.h, and I think that would be ill advised. GDB relies on case sensativity vis: (gdb) set remote P-packet off While at present there isn't an equivalent ``p-packet'' command, there will be. Having ``set remote p-packet'' one day map to ``P-packet'' and then, the next, map to ``p-packet'' would be confusing. > - charset.c should be changed to use an enum, for completion's sake. Wonder if there is a way of automatically testing on new commands. Andrew