fix(lidl): widen narrow ints so the generator can type them - #44
Open
dlipicar wants to merge 2 commits into
Open
fix(lidl): widen narrow ints so the generator can type them#44dlipicar wants to merge 2 commits into
dlipicar wants to merge 2 commits into
Conversation
LIDL numbers are 64-bit only, so `uint32_t depth` and `std::vector<uint32_t> instruction` had no LIDL type and were published as the opaque `any` — admitted by every backend gate, handed to the parameter with no decode and no check. logos-cpp-sdk#127 turns that silence into a build error, so declare them `uint64_t` / `[uint64_t]`. Widening is source-compatible for every caller. The wallet FFI stays 32-bit (wallet_ffi_restore_data takes a uint32_t depth, both wallet_ffi_send_generic_*_transaction take const uint32_t*), so narrow at that boundary and refuse a value that does not fit rather than truncating it — a truncated instruction word is a different instruction. The published .lidl now reads `depth: uint` and `instruction: [uint]`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The depth guard returned INVALID_INPUT, which exists only in tests/stubs/wallet_ffi.h. The real header has no such enumerator, so the module failed to compile against it even though the unit tests — which link the stub — passed: src/lez_core_module.cpp:1204:16: error: use of undeclared identifier 'INVALID_INPUT'; did you mean 'INVALID_UTF8'? Use INVALID_TYPE_CONVERSION, which upstream defines and which says exactly what happened: a value that does not fit the target type. The stub gains that enumerator with its upstream value so the guards are still testable by name, plus a note that the stub is NOT a mirror of the real header — the names are a subset and the values disagree (INTERNAL_ERROR is 1 here, 99 upstream), so a numeric assertion against an FFI code tests the stub rather than the module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There's some implicit conversions in the module API we currently do on the codegen side that will become build errors in the near future.
Only 64-bit integers are currently supported in module interfaces (support for smaller ones will come later). Adding explicit narrowing to 32-bit with the proper checks so nothing changes wallet-ffi-side.
These methods are not consumed by any UI, as far as I could see.