From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFA] Fix regression in "commands"
Date: Fri, 01 Dec 2017 16:45:00 -0000 [thread overview]
Message-ID: <87vahq5rcw.fsf@tromey.com> (raw)
In-Reply-To: <3a860acf-6e64-b2ba-e3fd-560406077259@redhat.com> (Pedro Alves's message of "Tue, 7 Nov 2017 10:49:15 +0000")
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> Hmm, for the truly "no breakpoints specified" case,
Pedro> it seems to me that before we can reach this error, we've already
Pedro> hit the error at the top of map_breakpoint_numbers:
Pedro> if (args == 0 || *args == '\0')
Pedro> error_no_arg (_("one or more breakpoint numbers"));
Pedro> and for the case where the user specifies some argument
Pedro> that doesn't match any breakpoint, map_breakpoint_numbers
Pedro> already printed one of:
Pedro> warning (_("bad breakpoint number at or near '%s'"), p);
Pedro> printf_unfiltered (_("No breakpoint number %d.\n"), num);
Pedro> when the "No breakpoints specified." error is reached.
I think the problem is that if the error call is removed from
commands_command_1, then a failure here won't throw at all, because
map_breakpoint_number_range just prints a message (either with warning
or printf_unfiltered -- not sure why the discrepancy), and doesn't
throw.
But, this would mean that an script erroneously using "commands" would
not be interrupted, which seems like maybe a bad result. Though, as you
point out, "delete" doesn't do this, so maybe it is ok?
Making map_breakpoint_number_range throw would mean that the case where
you have breakpoint 2 and do "commands 1-3" would now fail -- although
that's worked with a warning since ranges were added.
Tom
next prev parent reply other threads:[~2017-12-01 16:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 19:07 Tom Tromey
[not found] ` <3a860acf-6e64-b2ba-e3fd-560406077259@redhat.com>
2017-12-01 16:45 ` Tom Tromey [this message]
2017-12-04 15:50 ` Pedro Alves
2017-12-07 18:13 ` Tom Tromey
2017-12-07 18:27 ` Pedro Alves
2017-12-01 16:56 ` Tom Tromey
2017-12-04 15:55 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vahq5rcw.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox