raise failing fmtCall example

[rianhughes]

#501

approve(sender,amount) is called on StarkGate: ETH Token using a wallet (Bravos Cairo 0 account). However, the SDK computes the incorrect call data format.

The call data formatting logic is in FmtCallData()

// https://goerli.voyager.online/tx/0x6fdae8a037508ececc5684406cdd66101d56004bf461c9ee7a3b7f5cf5bb799

Expected call data :
[
0x1 
0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7 0x219209e083275171774dab1df80982e9df2096516f06319c5c6d71ae0a8480c 
0x0 
0x3 
0x3 
0x43784df59268c02b716e20bf77797bd96c68c2f100b2a634e448c35e3ad363e 
0x21 
0x0
], 

// See the new test

Computed call data :
[
0x1 
0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7 
0x219209e083275171774dab1df80982e9df2096516f06319c5c6d71ae0a8480c 
0x0 
0x2 
0x2 
0x43784df59268c02b716e20bf77797bd96c68c2f100b2a634e448c35e3ad363e 
0x21]

[rianhughes]

It's not clear whether this is an issue with the SDK or not. Internal discussions suggest the formatting logic is correct. However, it seems that the approve(sender,amount) function needs an additional "0" passed to it.

[jmouvill]

isn't it because the approve method expects an u256: https://testnet.starkscan.co/contract/0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7#read-write-contract-sub-write ?
For u256 type, starknet seems to expect 2 felts, the first one containing the lowest 128 bits and the second containing the 128 highest bits.
That's why here you would need to add the extra 0x0, representing the 128 highest bits of the u256 (here it's 0).
What do you think ?