Boost C++ Libraries: Ticket #5689: lexical_cast must understand "inf" and "nan"

status changed; resolution set

Antony Polukhin — Fri, 15 Jul 2011 11:20:14 GMT

status new → closed
resolution → fixed

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

Antony Polukhin — Sat, 16 Jul 2011 21:02:37 GMT

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

anonymous — Fri, 05 Aug 2011 00:58:29 GMT

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 — Fri, 05 Aug 2011 03:35:44 GMT

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 — Thu, 16 Feb 2012 04:22:42 GMT

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.

cc, status, type changed; resolution deleted

Antony Polukhin — Thu, 16 Feb 2012 17:24:44 GMT

cc antoshkka@… added
status closed → reopened
resolution fixed
type Bugs → Support Requests

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!

status changed; resolution set

Antony Polukhin — Thu, 16 Feb 2012 17:57:57 GMT

status reopened → closed
resolution → fixed

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

Antony Polukhin — Thu, 16 Feb 2012 17:59:33 GMT

Fixed in r77039