Re: [PATCH 1/2] use zuinteger_unlimited for some remote commands

[Pedro Alves <palves at redhat dot com>]

On 03/05/2013 05:33 PM, Doug Evans wrote:
> On Tue, Mar 5, 2013 at 4:59 AM, Pedro Alves <palves@redhat.com> wrote:
>> We could just as
>> well treat the variable internally as the correct type of
>> unsigned int, and handle UINT_MAX as unlimited internally too.
> 
> Part of me is weeping that we didn't take this route.

In a way, I suppose I don't like it, because it ties a
magic _positive_ number as upper bound in the user/api
interface.  And that also invites problems and tears
down the road.  :-)

IOW, the magic number UINT_MAX actually depends on
host int width (32/64-bit, etc., exotic, but they exist),
so e.g., in theory python scripts may have trouble with that.
Also, if at some point we want to extend the range of
these variables to 64-bit, the magic number has to change,
as then UINT_MAX is midway through the valid range...
Signed negative "-1", "-2", etc. don't have that issue.
They mean the same whatever the width.

(And if we want another magic number in addition to "unlimited"?
Say, we need "disabled", while "0" still meaning "0".
Reserving and writting "UINT_MAX-1" gets much uglier then...
Maybe we'll end up with a struct instead of packing things
into a single number.)

That's a load of theory though.  We could also just declare
the command is bound to a uint32_t variable, and document it as
such.

But still, OTOH, this same reasoning percolates all the
way to the remote protocol -- numbers in the remote protocol
don't actually have an upper bound / width hard coded.  So there's
a possible compatibility issue here.  Once UINT_MAX for one target
is deemed "not big enough", should we add new, different packets?
Or should GDB be adjusted to cope internally, while the visible
interfaces (cli/python/RSP) remain the same, only that they support
larger values?

The other approach (signed, -1) avoids actually thinking too
much about all these issues, and pondering on their
significance, hence my preference.  :-)

> If uinteger is in the name, anything else just invites problems, if
> not tears ... :-)

To me, it indicates that for "normal" values, this command only
really accepts positive values.  Negatives are almost an
implementation detail.  We could make it fully an implementation
detail, if "set foo unlimited" was supported (I do think it should),
and, if that isn't actually problematic for frontends/python (is it?),
though I could imagine the negative values being more convenient in
scripts than having to check for special non-numbers.

With all that said -- it's fine with me if people remove the u.

-- 
Pedro Alves