Skip to content

Add int64_t support to embind using bigint support #13889

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
May 5, 2021

Conversation

cuberoot
Copy link
Contributor

This PR adds int64_t and uint64_t support to embind when the -s WASM_BIGINT flag is used (see issue 11726).

Emscripten has support for handling int64_t and uint64_t as JS bigint values, but embind does not know anything about those values.

This PR is incomplete. I need to add tests and work out how to add guards so that this change does not cause issues when the -s WASM_BIGINT is not used.

@welcome
Copy link

welcome bot commented Apr 13, 2021

Thank you for submitting a pull request! If this is your first PR, make sure to add yourself to AUTHORS.

Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work, thanks @cuberoot ! I think this is correct.

Please add testing for this, I think otherwise it looks good.

@RReverser maybe you want to take a look too?

Copy link
Collaborator

@RReverser RReverser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

Michael Taylor added 2 commits April 15, 2021 19:28
* add range check and numeric conversions to toWireType implementation for int64_t and uint64_t
* add basic test for emscripten::val and 64-bit bigints
* fix indentation issue

var isUnsignedType = (name.indexOf('u') != -1);

// maxRange comes through as -1 for uint64_t (see issue 13902). Work around that temporarily
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See issue #13902

@cuberoot
Copy link
Contributor Author

I added more intelligence to the toWireType, so check that out.

I will add more tests for binding function calls tomorrow.

- Fix issue with `val::as<int64_t>()` not working
- Add more tests for `val` and embind with `int64_t` and `uint64_t`
- Fix failing tests using suggestion from Kripken
@@ -190,6 +192,8 @@ namespace emscripten {
const void* p;
} w[2];
double d;
int64_t i;
uint64_t u;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need both signed and unsigned? i'd hope only unsigned is enough, as with unsigned u above for 32-bit values.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kripken You are correct, the int64_t member was redundant.

Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@kripken kripken merged commit cf9f2c9 into emscripten-core:main May 5, 2021
@cuberoot cuberoot deleted the cuberoot/embind-int64 branch May 11, 2021 22:03
RReverser added a commit to RReverser/emscripten that referenced this pull request Jun 16, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone.

However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner.

There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately.

Fixes emscripten-core#24547.
RReverser added a commit to RReverser/emscripten that referenced this pull request Jun 16, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone.

However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner.

There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately.

Fixes emscripten-core#24547.
RReverser added a commit to RReverser/emscripten that referenced this pull request Jun 17, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone.

However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner.

There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately.

Fixes emscripten-core#24547.
RReverser added a commit to RReverser/emscripten that referenced this pull request Jun 17, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone.

However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner.

There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately.

Fixes emscripten-core#24547.
RReverser added a commit to RReverser/emscripten that referenced this pull request Jun 17, 2025
This is the next step in refactorings I started back in emscripten-core#20383 to merge all Embind generic method callers into a single mechanism. I never got around to landing this PR because I kept trying to split it into even smaller changes / steps, never found a good way to do so due to how entangled they were, got frustrated and left it alone.

However, aside from being a nice-to-have optimisation or cleanup refactoring, it's also an easy way to deal with issues like emscripten-core#24547 which makes it a bit more pressing. Without this PR, we'd have to duplicate the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from emscripten-core#13889 for `emval_call` and `emval_call_method` as well, but after this PR everything goes through the same centralised implementation where we can deal with all Embind types in a consistent manner.

There are some more things that I'd like to clean up here (including some of the complexity added by this very own PR), but in order to try and keep review scope smaller, I'm going to submit them separately.

Fixes emscripten-core#24547.
sbc100 pushed a commit that referenced this pull request Jun 17, 2025
This is the next step in refactorings I started back in #20383 to merge
all Embind generic method callers into a single mechanism. I never got
around to landing this PR because I kept trying to split it into even
smaller changes / steps, never found a good way to do so due to how
entangled they were, got frustrated and left it alone.

However, aside from being a nice-to-have optimisation or cleanup
refactoring, it's also an easy way to deal with issues like #24547 which
makes it a bit more pressing. Without this PR, we'd have to duplicate
the `emval_as`+`emval_as_int64`+`emval_as_uint64` fix from #13889 for
`emval_call` and `emval_call_method` as well, but after this PR
everything goes through the same centralised implementation where we can
deal with all Embind types in a consistent manner.

There are some more things that I'd like to clean up here (including
some of the complexity added by this very own PR), but in order to try
and keep review scope smaller, I'm going to submit them separately.

Fixes #24547.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants