This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Handle var_zuinteger and var_zuinteger_unlimited from Python
- From: Tom Tromey <tom at tromey dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Wed, 02 May 2018 10:05:01 -0600
- Subject: Re: [RFA] Handle var_zuinteger and var_zuinteger_unlimited from Python
- References: <20180426222003.9059-1-tom@tromey.com> <20180430215210.ngeru74jibhlgxul@adacore.com>
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
Joel> This patch looks good to me, and you can push as is. It was surprisingly
Joel> harder to read (I picked this patch as a way to spend my time constructively,
Joel> while I wait for a build to finish ;-)), in particular the part with
Joel> the fall through in the case statement, but that's probably me having
Joel> a slightly different type of brain... I managed to convince myself
Joel> that the patch looks correct to me.
Yeah, that bit is really unclear in the patch, but clearer (IMO) in the
code:
case var_uinteger:
if (l == 0)
l = UINT_MAX;
/* Fall through. */
case var_zuinteger:
ok = (l >= 0 && l <= UINT_MAX);
break;
Joel> One thought: How about testing the value of the setting after setting
Joel> its value to -1?
I've added a test like so:
gdb_test "python print(gdb.parameter('test-$kind'))" "-1" \
"check that PARAM_ZUINTEGER value is -1 after setting"
Tom