lexical_cast must understand "inf" and "nan"

[Antony Polukhin]

Some libraries and compilers understand "inf","+inf","nan", and some - not.
Make lexical_cast understand such input and do not depend on particular stringstream/scanf realization.

[Antony Polukhin]

(In [73118]) Fixes #5689. Added code to work with Inf and NaN on any platform

[Antony Polukhin]

(In [73155]) Fixes #5689. Added code to work -NaN on any platform. Removed some warnings

[anonymous]

please backport this to 1.47 - it's ridiculous that it doesn't work as expected already. I just converted the code which triggered this bug to use stringstream directly but I love to use lexical_cast for it's shortness.... and 1.48 is too far off.

[Antony Polukhin]

It is impossible, because:

• it depends on functions of boost::math that exist only in trunk
• this patch depends on some previous patches for lexical_cast that are only commited in trunk version and are not fully tested
• this fix is a workaround for some rare compiler error, it can wait till 1.48

stringstream won`t help you, in 1.47 lexical_cast uses stringstream to convert float types. And VC++ hav no problems with conversion.

You can always use a trunk version of boost. It will bring you all the new (but not always stable) features.

[anonymous]

using 1.48 version of lexical_cast works for "nan" but throws a error for "NaN". I do not think there is a formal specification for Not-A-Number in string form, but "NaN" is a common usage form.

[Antony Polukhin]

Replying to anonymous:

using 1.48 version of lexical_cast works for "nan" but throws a error for "NaN". I do not think there is a formal specification for Not-A-Number in string form, but "NaN" is a common usage form.

There is a formal specification for Not-A-Number strings. According to standard strtod, strtof, and strtold, scanf, sscanf and fscanf functions must parse NaN like that:

The expected form of the subject sequence is an optional plus or minus sign, then one of
the following:
— INF or INFINITY, ignoring case
— NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part, where:
...

Last time I`ve been confused by printf functions, they have more strict rules for outputting NaNs:

A double argument representing an infinity is converted in one of the styles
[-]inf or [-]infinity — which style is implementation-defined. A
double argument representing a NaN is converted in one of the styles
[-]nan or [-]nan(n-char-sequence) — which style, and the meaning of
any n-char-sequence, is implementation-defined. The F conversion specifier
produces INF, INFINITY, or NAN instead of inf, infinity, or nan,
respectively.

Great thanks for reporting this bug!

[Antony Polukhin]

(In [77040]) More tests for fixed #5689 (issue mentiond in 5th comment)

[Antony Polukhin]

Fixed in r77039