Re: inf and nan in arithmetic expansions

[Vincent Lefevre <vincent@vinc17.net>]

On 2018-02-27 16:25:47 +0100, Oliver Kiddle wrote:
> Vincent Lefevre wrote:
> > > This is actually system specific. We generate whatever printf(3)
> > > generates. Try out Stephane's examples on Solaris and you get Inf and
> > > NaN instead. I think I prefer those forms. We can make the printf code
> > > detect them and hard code a consistent form so that we are consistent
> > > across platforms.
> >
> > What do you mean by "We generate whatever printf(3) generates."?
> 
> Zsh calls printf(3) to do the work underneath. The following code:
>   #include <stdio.h>
>   int main() { printf("%g\n", 1e9999); }
> Will output "Inf" on Solaris and "inf" on Linux (for glibc at least).
> And the zsh printf builtin does likewise on each platform.

Solaris is broken. The ISO C99 and C11 standards say:

  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.

Thus for the above example, the correct outputs are "inf" and
"infinity".

> > On Debian/unstable:
> >
> > cventin% echo $((1e9999))
> > inf.
> 
> That trailing . is unrelated. It is added to ensure floating point types
> remain floating point which is not applicable to Inf and NaN.

OK, so whatever printf(3) generates and a trailing ".".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)