Re: inf and nan in arithmetic expansions

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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.

> 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.

> cventin% printf "%g\n" 1e9999
> cventin% /usr/bin/printf "%g\n" 1e9999

How 1e9999 is interpreted a different matter. Zsh first tries strtod()
then full zsh math evaluation. So printf "%g\n" 3+4 works in zsh but not
coreutils' printf.

I do intend to get the patch cleaned up and a follow-up submitted but it
has been a busy time.

Oliver