From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: eliz@is.elta.co.il, gdb@sources.redhat.com, insight@sources.redhat.com
Subject: Re: Register group proposal
Date: Thu, 22 Feb 2001 08:46:00 -0000
Message-id: <3A9541C4.EA9C2FAF@cygnus.com>
References: <Pine.SUN.3.91.1010222105511.1660T-100000@is> <200102221237.f1MCbtX02766@rtl.cygnus.com>
X-SW-Source: 2001-02/msg00299.html

Nick Duffek wrote:
> 
> On 22-Feb-2001, Eli Zaretskii wrote:
> 
> >If we are to use an iterator, shouldn't the test in this loop be
> >abstracted as well, like this, for instance?
> 
> Not necessarily: something like REGGROUP_FIRST_REGNUM and
> REGGROUP_NEXT_REGNUM are required for implementing multiple groups, but
> REGGROUP_NOT_LAST_REGNUM isn't.
> 
> REGGROUP_NOT_LAST_REGNUM is consistent with the notion of changing integer
> register numbers into opaque identifiers (aka handles or cookies).
> 
> But declaring that -1 is a reserved register identifier doesn't tie our
> hands much interface-wise.  It works pretty well for various UNIX file and
> memory interfaces.
> 
> Maybe we need to establish some GDB coding policies about handles defined
> and passed around by abstract interfaces: should they be ints, struct
> pointers, typedefs, etc., and should there be a known-invalid value such
> as -1 or NULL?

To add to this, there are two classes of iterators:

	o	like the above where things don't
		change under your feet.

	o	nasty ones where where you're
		doing a transformation.  Vis:

		for everything in the old group
		   if blah
		      it stays in the group
		   else
		      it is removed from the group

		breakpoints have this problem but
		per my other comment that is a very
		separate problem to what is happening
		here.

For the simple first case, I think it is reasonable for a programmer to
expect the corresponding code to look like either:

	int group;
	for (group = ...; group >= 0; group = ...) { ... };
or
	struct reggroup *group;
	for (group = ...; group != NULL; group = ...) { ... }'

since in each case they are the natural sentinal.

In the integer case, the only thing I would encourage is that the test
be the looser but more robust ``... >= 0'' rather then the very exact
``... == -1''.

	Andrew