Re: [RFA] deleting breakpoints inside of 'commands' (again)

[Don Howard <dhoward at redhat dot com>]

On Tue, 6 Nov 2001, Andrew Cagney wrote:

> > On Mon, 5 Nov 2001, Michael Snyder wrote:
> >
> >
> >> Fernando Nasser wrote:
> >
> >> >
> >> > Don Howard wrote:
> >
> >> > >
> >> > > This implementation makes a copy of commands list that contain 'delete'
> >> > > or 'clear' commands.  It also attempts to clean up when an error in
> >> > > encountered.  Comments?
> >
> >>
> >> Don, I hesitate to say anything, because I know this has been beaten
> >> to death already, but does this method account for the possibility that
> >> the list might contain a call to another user command which in turn
> >> calls "delete" or "clear"?
> >>
> >
> >
> >
> > Good point - I should have caught that.  In place of the strncmp()
> > calls in the previous patch, I've added a call to this:
>
> Er, this gets worse and worse.  What happens if the second level command
> being called deletes its self?
>

Doesn't the function below catch that?  There is a recursive call to
look for just the problem that you mention.  Is there some other way of
deleting commands that I need to look out for?


/* Walk a list of struct command_lines and try to determine if any
   command deletes breakpoints */

static int
bpstat_actions_delete_breakpoints (struct command_line * cmd)
{
  for (; cmd; cmd = cmd->next)
    {
      int i;

      if (strncmp (cmd->line, "del", 3) == 0 || 	/* delete */
	  strncmp (cmd->line, "cl", 2) == 0) 		/* clear */
	return 1;

      for (i=0; i<cmd->body_count; i++)
	if (bpstat_actions_delete_breakpoints (cmd->body_list[i]))
	  return 1;
    }

  return 0;
}



[BTW, I personally think that the unconditional copy is much less
error prone (and therefore better) even if it's slower. Just my $0.02]


-- 
-Don
dhoward@redhat.com
gdb engineering