Fix amount displayed for tokens with non-8 decimals#39
Conversation
c9b0fb4 to
82d5cee
Compare
681aa93 to
7242979
Compare
cted-ledger
left a comment
There was a problem hiding this comment.
Thanks Paweł — the actual decimals fix is small and correct. The blocker is that it's buried under a repo-wide reformat done with the wrong style. A few targeted comments below; the main ask is to split this into focused PRs.
| buf.offset = 0; | ||
|
|
||
| return handler_get_public_key(&buf, (bool) cmd->p1); | ||
| return handler_get_public_key(&buf, (bool)cmd->p1); |
There was a problem hiding this comment.
This whole-repo reformat doesn't match the committed .clang-format and will fail the format CI. The repo config sets PointerAlignment: Right, SpaceAfterCStyleCast: true, SortIncludes: false, ColumnLimit: 100, but the diff does the opposite everywhere: command_t* cmd (should be command_t *cmd), (bool)cmd->p1 (should be (bool) cmd->p1), reordered includes, and wrapping at ~80 cols. Please re-run clang-format with the repo's .clang-format — that should make almost all of these ~30 files drop out of the diff.
| VERSION 1.0 | ||
| DESCRIPTION "Fuzzing of transaction parser" | ||
| LANGUAGES CXX) | ||
| LANGUAGES C CXX) |
There was a problem hiding this comment.
Out of scope for a decimals fix: the .cc->.c rename, LANGUAGES C CXX, and LINKER_LANGUAGE CXX change the fuzzing build (ClusterFuzzLite) and can break that CI job. Please move this to its own PR.
| #include <string.h> // memset | ||
|
|
||
| #include "os.h" | ||
| #include "../common/user_format.h" |
There was a problem hiding this comment.
Unrelated incidental change: this file's mode flips 100755 -> 100644. Worth reverting so the PR only contains intended changes.
| // Type id | ||
| typedef struct token_info { | ||
| const char ticker[MAX_TICKER_LENG]; | ||
| uint8_t decimals; |
There was a problem hiding this comment.
Root cause is a hardcoded static registry, so the wrong-amount bug recurs whenever the token list changes, and only one FA snapshot (test_sign_fa_tx) guards it. Could you add a short comment documenting where these decimals values come from (on-chain metadata source)? Not blocking.
7242979 to
a8766a2
Compare
a8766a2 to
e243a77
Compare
Checklist
developFixes #17302 (LIVE-30542).
Token amounts were formatted with a hardcoded 8 decimals while the ticker came from the token registry, so tokens that do not use 8 decimals (e.g. USDT, 6) showed the wrong amount (0.01 instead of 1.0). Added a
decimalsfield toTOKEN_MAPPINGand use it when formatting coin and fungible asset transfers; native APT, gas and staking keep 8 decimals, unlisted tokens keep the 8 decimals fallback.Snapshots updated:
test_sign_fa_tx(the fix) andtest_app_mainmenu(the version screen, from the bump).