1

working on a cross-platform calculator application, i just noticed that on W32 NaN/Inf values are converted differently to strings than on OSX/linux. namely.

linux/OSX uses nan rsp inf, whereas W32 uses something like 1.#INF resp. 1.#QNAN.

what's the canonical way to get an identical representation on all platforms?

i'd like to avoid manually checking values with isnan() and isinf() and hardcoding the inf resp nan string representations.

(i read some comment in What is the difference between IND and NAN numbers that the actual "culprit" is the libc implementation, rather than the platform).

Community
  • 1
  • 1
umläute
  • 28,885
  • 9
  • 68
  • 122
  • There just isn't one, no standard demands the *string* representation of the double value. Not even normal double values, sometimes a period and sometimes a comma. The MSVC representation is fairly wonky, you can make it a [lot more wonkier](https://blogs.msdn.microsoft.com/oldnewthing/20130228-01/?p=5103) :) You'll have to make it consistent yourself. – Hans Passant Apr 10 '17 at 22:04
  • What is tricker is that you likely also want the reverse too - changing text - and all its variants - into a NaN. – chux - Reinstate Monica Apr 10 '17 at 22:09

1 Answers1

1

In C11 (and maybe earlier), these representations are mandated by the spec, at least partially. From ISO/IEC 9899:2011, section 7.21.6.1 The fprintf function, paragraph 8:

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.

Anything more than that, you're going to be on your own for, I'm afraid.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469