[wasm64] convert BigInt<->Number based on library function __sig attributes
#16877
Conversation
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
|
This is just the initial change that introduces this concept. More widespread usage, and increased test coverage is coming in a followup. |
sbc100
force-pushed
the
automatic_signature_conversions
branch
2 times, most recently
from
d5cb46c to
32a18ed
Compare
Do we assume |
Yup that's already been hard-coded in since the start. |
|
Nice, this seems a more solid way to do it! |
aardappel
approved these changes
May 4, 2022
kripken
approved these changes
May 4, 2022
Great, thanks! |
sbc100
force-pushed
the
automatic_signature_conversions
branch
from
32a18ed to
5525cf8
Compare
sbc100
changed the title
__sig attributes__sig attributes
sbc100
force-pushed
the
automatic_signature_conversions
branch
4 times, most recently
from
12d3cfd to
c298297
Compare
sbc100
force-pushed
the
automatic_signature_conversions
branch
from
c298297 to
f058030
Compare
…tributes This change introduces and type to the `__sig` scheme that we using for library functions: 'p'. This letter signifies that the parameter or return value is the width of a pointer which means it will differ between wasm32 and wasm64. We use this whenever a JS function receives or returns pointer type or a size_t type. For wasm32, we don't need to do anything since the incoming value is and i32. For wasm64 we convert the incoming BigInt value to an int53/double at the JS/Wasm boundary. At the moment no checking is done on the values, which means values that don't precisely convert to JS double can be corrupted/truncated. As a followup, we could consider using the checking conversion functions, or asserting in debug builds if the values don't fit within this range.
sbc100
force-pushed
the
automatic_signature_conversions
branch
from
f058030 to
fcfa6b5
Compare
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.
This change introduces and type to the
__sigscheme that we using forlibrary functions: 'p'. This letter signifies that the paramater or
return value is the width of a pointer which means it will differ
between wasm32 and wasm64.
We use this whenever a JS function receives or returns pointer type or a
size_t type.
For wasm32, we don't need to do anything since the incoming value is and
i32. For wasm64 we covert the incoming BigInt value to an int53/double
at the JS/Wasm boundary. At the moment no checking is done on the
values, which means values that don't pricely convert to JS double can
be currupted/truncated. As a followup, we could consider using the
checking coversion functions, or asserting in debug builds if the values
don't fit within this range.