This is the mail archive of the
mailing list for the GDB project.
Re: charset.c problem with non-en_US locales
Andrew Cagney <ac131313 at redhat dot com> writes:
(gdb) set charset <tab>
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:
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
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 <tab> on new commands.