When parsing floating-point from String, underflow to 0, overflow to ∞ #34339
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
…infinity
Previously, overflow and underflow both caused this to return `nil`, which causes several problems:
* It does not distinguish between a large but valid input and a malformed input. `Float("3.402824e+38")` is perfectly well-formed but returns nil
* It differs from how the compiler handles literals. As a result, `Float(3.402824e+38)` is very different from `Float("3.402824e+38")`
* It's inconsistent with Foundation Scanner()
* It's inconsistent with other programming languages
This is exactly the same as swiftlang#25313
Fixes rdar://problem/36990878
|
@swift-ci Please test |
|
Build failed |
tbkka
added a commit
to tbkka/swift-corelibs-foundation
that referenced
this pull request
Oct 17, 2020
The value `2.7976931348623158e+308` is a perfectly valid JSON number and should be accepted. This test is only passing today because the Swift standard library's `Double(_ String:)` initializer has a bug that rejected numbers larger than the maximum Double value. But we're getting ready to fix that bug in the Swift standard library, (swiftlang/swift#34339) which will break this test when it lands.
|
Right now, this is failing only on an invalid JSON parsing test in swift-corelibs-foundation. I've filed swiftlang/swift-corelibs-foundation#2903 to remove the invalid test, at which point this should be fine. |
stephentyrone
approved these changes
Oct 18, 2020
|
@swift-ci please test Linux |
spevans
added a commit
to spevans/swift-corelibs-foundation
that referenced
this pull request
Mar 8, 2021
- The behaviour of the floating point string parsing for Float and Double was changed to return +/-infinity instead of nil on overflow. (swiftlang/swift#34339) - Add an isFinite check to ensure that the result of a floating point conversion still fits in the type, matching current behaviour.
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.
Previously, overflow and underflow both caused this to return
nil, which causes several problems:Float("3.402824e+38")is perfectly well-formed but returns nilFloat(3.402824e+38)is very different fromFloat("3.402824e+38")Note: This is exactly the same as #25313 by @stephentyrone
Fixes rdar://problem/36990878