Re: [bug-gawk] Overflow to Infinity

[Daniel Pettet]

Hello,

Thank you for following up on this.  I agree with Arnold that there are two issue here and it is best to treat them separately.  The first is about decoding very large numbers that overflow to +/- infinity.  How the output is displayed is another problem that is more general in nature.  To solve the first problem the output should be 'inf' or '-inf' to be consistent with the rest of gawk.

Outputting '+inf' rather than 'inf' could solve the encode/decode round-about problem and is easier to spot since it looks numeric - which it is.  How easy this is to do depends greatly on how gawk is implement.

Solving the second problem will also have to include NaNs.  NaNs have signs in the floating-point unit but conceptually do not.  One could output '.nan' rather than '+nan' and '-nan' to solve the encode/decode round-about problem.  '.nan' also looks numeric.

Thanks.  Dan.

On 22 June 2018 at 08:55, Andrew J. Schorr <address@hidden> wrote:

Hi,

On Fri, Jun 22, 2018 at 03:15:16AM -0600, address@hidden wrote:
> > So gawk sets the numeric value to zero and decides that the input is
> > actually a string, not a number.
>
> Yes.
>
> > I'm not sure about the language lawyering on this topic. Perhaps one could
> > argue that an exception should be made for ERANGE.
>
> This thread had brought up two issues. Input is not getting converted
> "correctly", and gawk can output "inf" and/or "nan" since it relies on
> the output of the C library printf in such cases.

I don't follow. As I understand it, the two issues both relate to input, not
output:

1. Huge numeric values that cause strtod to overflow to inf or -inf were
returning ERANGE, and gawk was treating this as an error and forcing the
value to zero.

2. String values of "inf" and "infinity" are converted to zero when
not running with --posix, in contrast to +inf, -inf, +infinity, and -infinity,
which are converted to inf or -inf as expected.

> > diff --git a/node.c b/node.c
> > index fcd2bf3..b879e64 100644
> > --- a/node.c
> > +++ b/node.c
> > @@ -140,7 +140,7 @@ r_force_number(NODE *n)
> >             *cpend = save;
> >     }
> > 
> > -   if (errno == 0) {
> > +   if (errno == 0 || errno == ERANGE){
>
> You need a space between the close paren and the open brace.
>
> > Note: I'm not sure whether this patch is ideal, since it neglects to
> > reset errno to zero, as happens in the "else" clause. I don't know whether
> > that errno reset is actually needed...
>
> Reseting errno won't hurt and should probably be done.

I modified this to set errno = 0 in that case. Or do you prefer to have
separate logic for 'errno == 0' and 'errno == ERANGE'? It now needlessly
sets errno to 0 in the 'errno == 0' case, but that seemed less horrible
than duplicating the other logic.

> Andy, please update your patch and go ahead and push it to gawk-4.2-stable.
> Let's use Daniel's code as a new test case also, once you've added in
> your patch.  Can you handle that for me?

I pushed it just now.

> I want to think some more about handling output.

One of us is confued. I think this is an input issue, not an output issue. It's
a question of how to convert "inf" and "infinity" in input -- are they strings
which have a numeric value of 0, or are they IEEE infinity values?

Regards,
Andy