Re: [PATCH v5 2/8] GDB/Python: Use None for `var_zuinteger_unlimited' value set to `unlimited'

["Maciej W. Rozycki" <macro@embecosm.com>]

On Fri, 24 Jun 2022, Andrew Burgess wrote:

> > Consistently with the `var_integer' and `var_uinteger' parameters return 
> > the special value of None for a `var_zuinteger_unlimited' parameter set 
> > to `unlimited' by using the Py_RETURN_NONE macro in this case, fixing 
> > commit 0489430a0e1a ("Handle var_zuinteger and var_zuinteger_unlimited 
> > from Python"); cf. PR python/20084.  Adjust the testsuite
> > accordingly.
> 
> Unfortunately, nice as it would be to make this change (for
> consistency), I think we're stuck with what we have.

 Yes, this does seem a bit risky, however we already have a documented 
precedent for a similar API correction:

 -- Function: gdb.breakpoints ()
     Return a sequence holding all of GDB's breakpoints.  *Note
     Breakpoints In Python::, for more information.  In GDB version 7.11
     and earlier, this function returned 'None' if there were no
     breakpoints.  This peculiarity was subsequently fixed, and now
     'gdb.breakpoints' returns an empty sequence in this case.

and here the peculiarity/inconsistency in my opinion is even more 
prominent.

> The -1 behaviour is documented for PARAM_ZUINTEGER_UNLIMITED in the
> manual so it is not unreasonable to assume that there could be code in
> the wild that relies on the existing behaviuor.

 Well, but that is not different from the two other cases, which have no 
mention of 'None':

'gdb.PARAM_UINTEGER'
     The value is an unsigned integer.  The value of 0 should be
     interpreted to mean "unlimited".

'gdb.PARAM_INTEGER'
     The value is a signed integer.  The value of 0 should be
     interpreted to mean "unlimited".

even they do return 'None' for "unlimited", and then as you say:

'gdb.PARAM_ZUINTEGER_UNLIMITED'
     The value is a signed integer.  This is like 'PARAM_ZUINTEGER',
     except the special value -1 should be interpreted to mean
     "unlimited".  Other negative values are not allowed.

 So what I think would be best to do here is actually (having missed the 
manual part before):

1. Accept (if we don't already; I haven't checked) and document 'None' as 
   input to parameters of these types, meaning "unlimited".

2. Deprecate and undocument but keep accepting special numeric values as 
   input to such parameters.

3. Produce and document 'None' as output for special "unlimited" numeric 
   values consistently from all such parameters.

Yes, there could be some fallout from such a change, however it should be 
easy to correct in Python code.  What would be a typical use case in 
Python code for retrieving these parameters?  And how is 'None' handled by 
Python when just passed to a `print' like standard routine to present it 
to the user?

 Given that PARAM_ZUINTEGER_UNLIMITED has been retrofitted chances are its 
handling in user code has been as well to existing code for PARAM_UINTEGER 
and PARAM_INTEGER, and it may already handle 'None' for all the three by 
default, before going on to special-casing the special values actually 
documented.

 Please let me know what you think, and thank you for your review.

  Maciej