[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    Re: [PATCH v7 2/4] GDB: Allow arbitrary keywords in integer set commands
From:       Simon Marchi via Gdb-patches <gdb-patches () sourceware ! org>
Date:       2022-10-31 19:22:31
Message-ID: 146021e6-41cb-22d3-6cec-06aed5818867 () simark ! ca
[Download RAW message or body]



On 10/31/22 14:48, Simon Marchi via Gdb-patches wrote:
> 
> 
> On 10/29/22 09:53, Maciej W. Rozycki wrote:
>> Rather than just `unlimited' allow the integer set commands (or command 
>> options) to define arbitrary keywords for the user to use, removing 
>> hardcoded arrangements for the `unlimited' keyword.
>>
>> Remove the confusingly named `var_zinteger', `var_zuinteger' and 
>> `var_zuinteger_unlimited' `set'/`show' command variable types redefining 
>> them in terms of `var_uinteger', `var_integer' and `var_pinteger', which 
>> have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
>>
>> Following existing practice `var_pinteger' allows extra negative values 
>> to be used, however unlike `var_zuinteger_unlimited' any number of such 
>> values can be defined rather than just `-1'.
>>
>> The "p" in `var_pinteger' stands for "positive", for the lack of a more 
>> appropriate unambiguous letter, even though 0 obviously is not positive; 
>> "n" would be confusing as to whether it stands for "non-negative" or 
>> "negative".
> 
> We don't have to restrict ourselves to a single letter.  By the end of
> reading the commit message, I had already forgotten what the `p` stood
> for.  Ideas:
> 
>  - var_non_negative_integer
>  - var_zero_or_positive_integer
>  - some better suggestion
> 
> On the other hand, is there any reason why "pintegers" couldn't be
> stored as var_uinteger, with the proper literal_def?
> 
> Simon

I forgot: I didn't have significant comments on the code itself.  Maybe
the only strange thing is the fact that you pass the list of extra
literals in the erased_args structure.  I don't think it should be
there, it's not something that need to be type-erased (cast to void).

Simon
[prev in list] [next in list] [prev in thread] [next in thread]