Re: [RFC] Clean up var_integer/var_uinteger/var_zinteger mess

[Daniel Jacobowitz <drow@false.org>]

On Wed, Feb 01, 2006 at 10:49:22AM -0800, Jim Blandy wrote:
> On 2/1/06, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > Actually, it'd make sense if the existing
> > var_integer/var_uinteger/var_zinteger would accept "unlimited".
> > That'd make your var_limit unnecessary.
> >
> > Does anyone see any problems with that?
> 
> Well, I presume that sometimes (often) those are used for limits of
> something, and sometimes they're genuine integers.  Surely there's
> something in GDB where a negative value would make sense.  I don't
> like the idea of accepting "unlimited" for a quantity that isn't a
> limit on anything.
> 
> Then, of course, there's aix-thread.c which is using zinteger for a boolean.

There's lots of (mis- ?) uses of all the var_ types all over GDB.  I
think that (A) we ought to clean them all up, and (B) it's going to
require checking them all to do it.  Definitely some of the current
uses don't make sense - for instance:

(gdb) show remote hardware-breakpoint-limit 
The maximum number of target hardware breakpoints is 4294967295.

A bunch of others ought to be booleans.  A bunch of others are actual
integer values - sometimes signed would make sense, sometimes it
wouldn't, e.g. ser-go32.c.

I'd like to be able to set the ones that are limits to "unlimited".
Caveats are preserving the existing "set to zero" behavior where it
makes sense to do so, updating the manual, and not being able to set
non-limits to unlimited.

-- 
Daniel Jacobowitz
CodeSourcery