As I said in the thread about possibly changing the ECDSA curve bitcoin uses, programmers like to solve "problems" that they know they can solve and that they think will make things a little bit better. But, in my humble opinion, unless you're solving an important problem changing things because you think you know how is often a bad idea.
This is a perfect example: change the RPC to spit out 64-bit integers (or move to a new RPC that spits out integers) and anybody using jansson on a 32-bit-int platform will get an overflow error.
OR, anyone using jansson would simply have to use (non-fractional) floats. As mentioned earlier, float types can represent the full range of base bitcoins fine, so long as they're not represented as decimal values.
I kind of like tcatm's suggestion to define new RPC methods that specify a base unit using strings... but then I thought more about it:
We could use scientific notation, so 1 BTC would be 1e08 base units; then if we ever needed more precision the JSON interface wouldn't change, you could just specify 1e-03 as a value....
... but that's exactly what we have now. 1 BTC is 1e00, 1 base unit is 1e-08, and if we ever needed more precision the JSON interface is ready.
1e8 is a perfectly legal JSON number. 1 BTC
shouldn't be 1e00, it
should be 1e8. And no matter how it is written (0.001 or 1e-03), the fractional-floating-point issues remain.
This works fine with the neutral branch: ./bitcoind -rpcversion=1 sendtoaddress 1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo 1e8