[RPC] Various rpc argument fixes

[instagibbs]

Audited where named args will fail to use correct default values or may fail when additional optional arguments are added.

Previously for these parameters, it was fine to omit them as positional arguments, but it would trigger UniValue runtime errors to set them to null, or to omit them while passing named parameters with greater positions (which would internally set earlier missing arguments to null). Now null values are treated the same as missing values so these errors do not occur.

Included a few other small fixes while working on it.

I didn't bother fixing account-based rpc calls.

[ryanofsky]

utACK 0ff520d. This is a nice PR, and gets rid of most of the cases where null arguments are treated differently than missing arguments. There are few cases not handled here (getbalance, lockunspent) that are handled in master...ryanofsky:pr/multiopt, but these could be taken care of in a followup.

Note that if we wanted to, we could easily enforce that missing arguments are treated the same as null arguments by making a change like 3fc286b.

[ryanofsky]

In commit "check for null values in rpc args and handle appropriately"

Instead of writing request.params.size() > X && !request.params[X].isNull() everywhere, I think you should just prefer !request.params[X].isNull(). The UniValue array implementation has bounds checking built in and already returns null for missing elements.

[promag]

Needs rebase, #10589 added more RPC arguments.

[instagibbs]

@ryanofsky since things are moving underneath me I'll leave the code simplification for a follow-up PR

now covering the getbalance and lockunspent cases

[ryanofsky]

Conditional utACK 03de1b6 if the getbalance and lockunspent changes are reverted.

@ryanofsky since things are moving underneath me I'll leave the code simplification for a follow-up PR

I don't see a reason to go through this whole process again in another PR. You can simplify your PR right now by running:

git checkout rpcargfixes # (assuming 03de1b66d560164187120711468e1e84c197df37)
git log -p -n1 | git apply -R
git log -p -n1 | sed '/+/s/request.params.size() > \([0-9]\) && \(!request.params\[\1\]\)/\2/' | git apply
git commit -a --amend --no-edit
git push -f

[ryanofsky]

Please revert this line. This is treating a null account the same as the default account ("") instead of treating a null account the same as an unspecified account (params.size() == 0), which you would need to do by changing the params.size() check above (like I did in master...ryanofsky:pr/multiopt and verified with 3fc286b).

[ryanofsky]

Should revert this line too. This is pointless because of the type check above.

I think it's best to stick to just handling the simple cases of missing values being treated differently from null values in this PR and handle the other cases more thoughtfully in another PR. Again, I already have the changes to do this in my multiopt branch, and would be happy to post a followup that builds on your change.

[instagibbs]

reverted two changes as suggested and simplified PR(need to improve my sed foo)

[ryanofsky]

utACK 1ab6cc0 if the bug in ListReceived (see below) is fixed. Change looks good and gets rid of most of the cases where code treats null arguments different from missing arguments.

[ryanofsky]

Missing ! here

[TheBlueMatt]

utACK 534963d

[ryanofsky]

utACK 534963d. Unchanged except bugfix in ListReceived.

[ryanofsky]

Needs rebase. Would be nice to have more review, too because (as mentioned) I'd like to do some more cleanup on top of this.

[instagibbs]

rebased

[promag]

Minor nits, otherwise utACK.

[promag]

Remove request.params.size() == 1 &&?

[promag]

Avoid negation?

return GetNetworkHashPS(request.params[0].isNull() ? 120 : request.params[0].get_int(), request.params[1].isNull() ? -1 : request.params[1].get_int());

[ryanofsky]

utACK 4dc1915. No changes since previous other than rebase to avoid conflict with recent fee estimation change on adjacent line.

Might be good to clarify PR description to say how this change affects behavior. Previously for these parameters, it was fine to omit them as positional arguments, but it would trigger UniValue runtime errors to set them to null, or to omit them while passing named parameters with greater positions (which would internally set earlier missing arguments to null). Now null values are treated the same as missing values so these errors do not occur.

[promag]

This could be simplified to:

bool fVerbose = false;
if (request.params[1].isNum()) {
    fVerbose = request.params[1].get_int() != 0;
} else if (!request.params[1].isNull()) {
    fVerbose = request.params[1].get_bool();
}

With the advantage of removing custom error handling.

[sipa]

utACK 4dc1915. @promag has a number of useful suggestions that could be included.

[gmaxwell]

Concept ACK

[sipa]

I would like to see this in 0.15 still - it's effectively (at least partially) fixing the incomplete support for named arguments introduced in the previous version.

[instagibbs]

for the purpose of getting this merged as a 0.15 bugfix I'm going to avoid invalidating review for nits (unless told otherwise)

[laanwj]

utACK 4dc1915, I didn't know univalue returned NullUniValue for out-of-bounds accesses, I always wrote bound checks, but this is better.