[SR-2626] String to Double conversion fails on "snan" input

[gribozavr]

Previous ID	SR-2626
Radar	rdar://problem/26720376
Original Reporter	@gribozavr
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug, StarterBug
Assignee	@hartbit
Priority	Medium

md5: ba2c6f38b18ec9c711fa49aecc0453e6

Issue Description:

The string -> floating-point intializer doesn’t allow you to create signaling NaN values. In the following code, y == nil, but should have the same value as x:

let x = Double(nan: 0, signaling: true) // OK
let y = Double("snan") // nil

This relates to section 5.12.1 of IEEE 754:

Conversion of an external character sequence “snan” (regardless of case) with an optional preceding sign, to a supported format should either produce a signaling NaN or else produce a quiet NaN and signal the invalid operation exception.

[swift-ci]

Comment by W S (JIRA)

The issue seems to be with strtof_l/strtod_l/swift_strtold_l not handling "snan" while they do handle everything else ("nan", "3.5", etc...)
Perhaps "snan" can be intercepted at _swift_stdlib_strtoX_clocale_impl (there's 2, a separate one for windows, and Android seems to just call strtof_l/strtod_l/swift_strtold_l directly).
https://github.com/apple/swift/blob/master/stdlib/public/stubs/Stubs.cpp

So I was curious about when snan should signal:
could it signal just from parsing+assigning (the 'nan' would pass into a FP register)?
Is it supposed to be SIGFPE or something else? (If something else, how is it caught/recognized?)

[stephentyrone]

"snan" should produce a signaling NaN value. On some platform ABIs (i386, basically) the act of loading/storing that value may result in a signal and the value being converted to a quiet NaN. That's OK. On other platforms, it will signal invalid when it is first used in arithmetic (that's OK too!)