Unexpected negative quantity for transactions

[digitaldonkey]

Unexpected negative quantity for transactions

[sebnyc]

Sure. You can try :

$tr = $eth->eth_getTransactionByHash(new EthD32("0x527e9b670536c09fe160b0c2e33728eadd7f8affae7803049fa8d8ec2d1c7cfe"));
echo $tr->value->val();

I currently outputs -493447593709551616 whereas the expected value is 1122081030000000000.

[digitaldonkey]

Can you provide a example to test against?

[sebnyc]

@digitaldonkey I'm not sure I understand how the EthQ class is used for RLP decoding, so I don't feel comfortable providing a pull request for this one.
Do you have any hint on how to fix that ?

[digitaldonkey]

My current guess is that the block number is actually not a EthQ as it is not padded as far as I remember.
Looking into it now.

[sebnyc]

Yes I confirm that the block number is not padded, that's what I see in my tests with my Parity node.
And same thing for many other attributes (transaction value, nonce, gasPrice, gas, gasUsed, block difficulty, gasLimit,...).

[digitaldonkey]

Assuming that data types are implemented consistently was a very naive idea of mine ;)

My approach so far was to use the Library to make them consistent - independently from the actual client.

[digitaldonkey]

Fixed in dev branch.

Deprecated unpadded negative hexadecimal numbers.

[sebnyc]

@digitaldonkey Nice, thank you !
That should do the trick. Can't wait to test it.