This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[COMMIT (mainline+7.6) PATCH] Fix range validation of integer commands with "unlimited". (was: Re: [COMMIT (mainline+7.6) PATCH] Fix PR gdb/15289 - "set remote hardware-watchpoint-limit" broken (zinteger commands))
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 22 Mar 2013 20:00:00 +0000
- Subject: [COMMIT (mainline+7.6) PATCH] Fix range validation of integer commands with "unlimited". (was: Re: [COMMIT (mainline+7.6) PATCH] Fix PR gdb/15289 - "set remote hardware-watchpoint-limit" broken (zinteger commands))
- References: <20130320192304 dot 7464 dot 3655 dot stgit at brno dot lan> <514BB619 dot 5070809 at codesourcery dot com>
On 03/22/2013 01:38 AM, Yao Qi wrote:
> I noticed this problem last year, and posted a patch
> http://sourceware.org/ml/gdb-patches/2012-09/msg00090.html
> I can't recall why I didn't ping it. Anyway, good to see the problem get fixed and thanks.
Bummer. Sorry I missed it before. :-( We did discuss this
regression in the context of the trace-buffer-size patch the
other week...
And I was about to post the patch below when I noticed
this email from you... Double :-(.
Your patch does handle val < 0 while mine wasn't doing
that. Not all is lost then.
I'm committing this to 7.6 and mainline.
Thanks.
-------------------------------
Subject: Fix range validation of integer commands with "unlimited".
The range validation added by
http://sourceware.org/ml/gdb-patches/2013-03/msg00767.html
Changes things to allow setting the command to INT_MAX or UINT_MAX
directly, with signed and unsigned commands respectively. However,
that went a little bit too far, as in the cases of var_integer and
var_uinteger, those values are actually implementation detail. It's
better to not expose them in the interface, and have users assume
those values mean "unlimited" too, so to be safer to expand the range
of the commands in the future if we want to. Yes, it's pedantic, and
it's not likely users actually will do this, but MI frontends and
Python scripts might.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
Mark Kettenis <kettenis@gnu.org>
* cli/cli-setshow.c (do_set_command) <var_uinteger>:
Don't let the user set the value to UINT_MAX directly.
<var_integer>: Don't let the user set the value to INT_MAX
directly.
---
gdb/cli/cli-setshow.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/gdb/cli/cli-setshow.c b/gdb/cli/cli-setshow.c
index 95ebbe7..81b90e7 100644
--- a/gdb/cli/cli-setshow.c
+++ b/gdb/cli/cli-setshow.c
@@ -278,7 +278,11 @@ do_set_command (char *arg, int from_tty, struct cmd_list_element *c)
if (c->var_type == var_uinteger && val == 0)
val = UINT_MAX;
- else if (val > UINT_MAX)
+ /* For var_uinteger, don't let the user set the value to
+ UINT_MAX directly, as that exposes an implementation detail
+ to the user interface. */
+ else if ((c->var_type == var_uinteger && val >= UINT_MAX)
+ || (c->var_type == var_zuinteger && val > UINT_MAX))
error (_("integer %s out of range"), plongest (val));
if (*(unsigned int *) c->var != val)
@@ -300,7 +304,12 @@ do_set_command (char *arg, int from_tty, struct cmd_list_element *c)
if (val == 0 && c->var_type == var_integer)
val = INT_MAX;
- else if (val > INT_MAX || val < INT_MIN)
+ /* For var_integer, don't let the user set the value to
+ INT_MAX directly, as that exposes an implementation detail
+ to the user interface. */
+ else if ((c->var_type == var_integer && val >= INT_MAX)
+ || (c->var_type == var_zinteger && val > INT_MAX)
+ || val < INT_MIN)
error (_("integer %s out of range"), plongest (val));
if (*(int *) c->var != val)