This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Also handle "set input-radix 0" and "set output-radix 0"
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 06 Jan 2009 11:58:44 -0700
- Subject: Re: Also handle "set input-radix 0" and "set output-radix 0"
- References: <200812292022.56780.pedro@codesourcery.com>
- Reply-to: tromey at redhat dot com
>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
Pedro> In addition, we can have "unlimited" radices:
Funny.
Pedro> I think that for these cases, a new var_zuinteger is what makes sense.
Pedro> Several other settings that fall in integer, uinteger or zinteger
Pedro> types currently, could/should move to this type.
Pedro> Anyone disagrees?
For the output radix, in reality we only support 3 possible values
(why not binary as well? I have no idea).
For the input radix... in practice I think the code also really only
supports bases <= 16. E.g., c-exp.y:parse_number says:
if (base > 10 && c >= 'a' && c <= 'f')
{
if (found_suffix)
return ERROR;
n += i = c - 'a' + 10;
}
I didn't check the other languages. However, given the above, I would
suggest validating the input radix as well.
Even if we want to support more input radices, there should still be
some limit, maybe 36 (10 numeric digits plus 26 alphabetic digits).
FWIW, my preference is not to support more. They lead to parsing
weirdness -- is "32u" an unsigned constant 32 in base 36?
I suspect that this kind of validation would mean we would not really
need var_zuinteger. I don't feel strongly about this, though, and it
does express the intent more clearly.
Tom