fundrawtransaction issues after #7518 #7889

#7518 introduced new compile warning:

  CXX      wallet/libbitcoin_wallet_a-rpcwallet.o
wallet/rpcwallet.cpp:2524:71: warning: comparison of integers of different signs: 'int' and 'size_type' (aka 'unsigned long') [-Wsign-compare]
    if (changePosition != -1 && (changePosition < 0 || changePosition > origTx.vout.size()))
                                                       ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~
1 warning generated.

What if the changePosition is specified as -1, what will happen after this code:

    if (changePosition != -1 && (changePosition < 0 || changePosition > origTx.vout.size()))
        throw JSONRPCError(RPC_INVALID_PARAMETER, "changePosition out of bounds");

ping @promag

There is also one in wallet.cpp:

+wallet/wallet.cpp:2183:50: warning: comparison of integers of different signs: 'int' and 'size_type' (aka 'unsigned long') [-Wsign-compare]
+                        else if (nChangePosInOut > txNew.vout.size())
+                                 ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~
+1 warning generated.

Or the GCC version of it:

CXX wallet/libbitcoin_wallet_a-rpcwallet.o wallet/rpcwallet.cpp: In function ‘UniValue fundrawtransaction(const UniValue&, bool)’:

wallet/rpcwallet.cpp:2524:90: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (changePosition != -1 && (changePosition < 0 || changePosition > origTx.vout.size()))

CXX wallet/libbitcoin_wallet_a-wallet.o wallet/wallet.cpp: In member function ‘bool CWallet::CreateTransaction(const std::vector<CRecipient>&, CWalletTx&, CReserveKey&, CAmount&, int&, std::string&, const CCoinControl*, bool)’:

wallet/wallet.cpp:2168:68: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] else if (nChangePosInOut > txNew.vout.size())

I don't expect this to ever be a problem. Anyway I can submit a PR to cast one of them. @laanwj WDYT?

These warnings are usually annoying at most, but anyone silencing them should take very much care that this doesn't introduce (or rather, obscure) potential overflows.

I'll fix this in #7857 .