No, the number that can be represented by the varint has no effect on the maximum number of inputs. That number is far too large. Rather the maximum number of inputs is constrained by the block size.
If it really matters to you what the maximum number that a varint can represent is, it's just the maximum value for a 64-bit integer. That's 0xffffffffffffffff. There's really no constraints on what a varint can represent. A transaction with such a number of inputs would not fit in a block, nor would it fit on any existing single storage medium as that transaction would be at least 664.1 Exabytes in size.
The maximum number of inputs that can fit in a valid transaction is 27022.
Such a transaction would not use segwit, so we use the maximum block size without segwit of 1000000 bytes. Subtract the 146 for the header and coinbase transaction to get 999854 bytes for the transaction. Subtract 4 bytes for the version, 4 bytes for the locktime, 1 byte for output count, 8 bytes for output value, 1 byte for output script, and 3 bytes for input count. This leaves us with 999833 bytes. With 37 bytes per input (32 previous txid, 4 output index, and 1 for script length), there can by 27022 inputs.
and 2 bytes for input countcorrection: it is 3 bytes because 27022 inputs inCompactIntis equal tofd8e69(it needs an initial0xfdto indicate 2 bytes follow up) – Coding Enthusiast – 2019-05-21T08:18:36.380@Anonymous What do you mean by "includes zero security"? – Jonathan Cross – 2019-05-21T16:26:21.103
Without signatures, all transaction in the block described here can be spent by anybody else. Including signatures reduces the number of inputs considerably. – Anonymous – 2019-05-21T17:09:48.470
2To note, that includes zero security or signatures. – Anonymous – 2019-04-02T06:11:56.287