Open dooglus opened 9 years ago
In the RPCTypeCheck
method @ https://github.com/nochowderforyou/clams/blob/master/src/rpcserver.cpp#L45
string err = strprintf("Expected type %s, got %s",
Value_type_name[t], Value_type_name[v.type()]);
throw JSONRPCError(RPC_TYPE_ERROR, err);
It appears this bug will display odd/overflow behavior with any RPC command executed with the standard int_type
check?
I would assume fixing the call to *.type()
might fix the underlying error as opposed to injecting additional checks into the listunspent
method itself.
This is fixed in the update from json_spirit to UniValue.
https://github.com/nochowderforyou/clams/pull/236
Is the pull request but has not been fully tested yet.
createrawtransaction and signrawtransaction especially need to be tested still.
This looks fixed so I'm going to close it. The test numbers you see here are 31 signed bits filled and +1.
$ cct listunspent 2147483647 [ ]
$ cct getblockbynumber 2147483647 error code: -1 error message: Block number out of range.
$ cct listunspent 2147483648 error code: -1 error message: JSON integer out of range
$ cct getblockbynumber 2147483648 error code: -1 error message: JSON integer out of range
I'll try and test createrawtransaction and signrawtransaction soon
I recently tried to list the unspent inputs in my wallet. Since there's no way I know of to ask for "all of them, mature or not", I typically ask for those with between 0 and 9999999999 confirmations, from any address, mature-or-not, like this:
... and that works. But this time I put too many 9's, and it returned an empty list:
It seems the extra 9 must have made the integer overflow, probably making it go negative, and so no outputs were found to match.
That's eleven 9's works, and twelve 9's doesn't.
Indeed, it's at 2^31 that the issue first happens: