This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
zinteger setshow commands broken
- From: Pedro Alves <palves at redhat dot com>
- To: "Abid, Hafiz" <hafiz_abid at mentor dot com>
- Cc: gdb-patches at sourceware dot org, stan at codesourcery dot com, yao at codesourcery dot com, eliz at gnu dot org
- Date: Fri, 01 Mar 2013 18:13:21 +0000
- Subject: zinteger setshow commands broken
- References: <1362157623.18212.0@abidh-ubunto1104>
On 03/01/2013 05:07 PM, Abid, Hafiz wrote:
>>
>>
>> Should probably be a LONGEST too. There's to reason to
>> actually limit to 31-bits, right?
>>
>> > + add_setshow_zinteger_cmd ("trace-buffer-size", no_class,
>> > + &trace_buffer_size, _("\
>>
>> Oh, I see... add_setshow_zinteger_cmd works with int...
> Observed that commands added with add_setshow_zinteger_cmd have problem with -1. For var_zinteger, do_set_command uses unsigned int and it ends up comparing 0xffffffff to INT_MAX. If it sounds like an oversight to you then I will send a patch. Here are those lines for a quick look.
> unsigned int val;
> ...
> val = parse_and_eval_long (arg);
> ...
> else if (val >= INT_MAX)
> error (_("integer %u out of range"), val);
>
Eh, indeed. Sounds like a regression. We have other
commands where -1 is treated specially:
(gdb) help set remote hardware-watchpoint-limit
Set the maximum number of target hardware watchpoints.
Specify a negative limit for unlimited.
(gdb) set remote hardware-watchpoint-limit -1
integer 4294967295 out of range
This surely worked at some point.
BTW, I think the new var_zuinteger_unlimited would be more
suitable. The difference is that "show" really shows "unlimited"
instead of -1. BTW2, IMO, "set" should accept literal "unlimited"
string as well too.
--
Pedro Alves