Bugfix for various strtol/strtoll issues #1209
Closed
Conversation
This file contains 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
|
I am hoping we will investigate porting an existing libc in the near future, yeah, definitely worth doing. |
|
Can you please rebase to remove the merge commits (and preferably also the dummy commit)? |
|
Done! |
|
Thanks. I also meant to also get rid of the other dummy commits, but I'll do that locally. |
|
Rebased and merged to incoming. Thanks! |
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 fixes a number of issues in the existing strtoll/strtol (and variants) implementation. Notably, this fixes issues when trying to parse hex numbers (0x...) with an undefined (=0) base where strtoll/strtol will (according to spec) resort to the string representation to identify the base.
A number of test cases for various bases (2, 8, 10, 16) is included.
Generally, we experience these sort of issues in "corner cases" fairly often with the existing stdlib implementation in library.js. In light of asm.js being so fast, I wonder whether emscripten wouldn't be better of by replacing most of that with an existing C library which has matured over time?