This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Also handle "set input-radix 0" and "set output-radix 0"


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]