Re: gawk 3.1.2g problems with NaNs and substr etc.

[Stepan Kasal]

Hello Paul,
        thank you very much for looking into this.  It's a combination
that noone has thought about yet (at least I have not).

On Sun, Jul 06, 2003 at 12:14:20AM -0700, Paul Eggert wrote:
> $ ./gawk-3.1.2g -W lint 'BEGIN {print substr("x", 1, 0.1)}' </dev/null
> gawk-3.1.2g: cmd. line:1: warning: substr: non-integer length 0.1 will be 
> truncated

this is OK.  Have I missed something?

> $ ./gawk-3.1.2g -W lint 'BEGIN {print substr("x", 1e300*1e300-1e300*1e300)}' 
> </dev/null
> $ ./gawk-3.1.2g -W lint 'BEGIN {print substr("x", 1, 
> 1e300*1e300-1e300*1e300)}' </dev/null

OK, when NaN appears we should detect it and treat it nicely.
substr() is one situation, but we should in fact audit the whole
source.

In numeric computation, gawk should probably treat NaN the same way as
the libc treats them.

In cases like string indexing, I'd like to see a warning whenever NaN is
encountered, even though the --lint option has not been switched on.

As GNU tools advertise "no-limits," there may be a situation where
a user computes
        pos1 = 1e300*1e300*line1
        pos2 = 1e300*1e300*line2
        .... substr(file, pos1/(1e300*1e300), (pos2-pos1)/(1e300*1e300))

So I think the patch should be much more complicated than what you have
posted.

OTOH, your patch modifies some texts, so it would delay the release because
all translators would have to translate the new messages.

I'd propose to put this issue off, after the 3.1.3 release.
But it's up to Arnold to decide this.

One more comment:
>       Be careful when comparing double to SIZE_MAX, as
>       the comparison might return the "wrong" answer when
>       (double) SIZE_MAX is a number that is not equal to
>       SIZE_MAX.

> @@ -1275,7 +1275,7 @@ do_substr(NODE *tree)
> -             if (d_length <= SIZE_MAX)
> +             if (d_length < SIZE_MAX)
>                       length = d_length;
>               else
>                       length = SIZE_MAX;

It took me some time to understand this.  I hope Arnold won't miss this
patch.  IMHO it could go to 3.1.3.

Stepan