[9front] Re: seq: fix infinite loop

[Anthony Martin <ality@pbrane.org>]

Sean Hinchee <henesy.dev@gmail.com> once said:
> наб on twitter, then over e-mail (CC'd) pointed out that seq(1) in
> 9front with some very large inputs
>
> For example:
>
>     ; seq 2e16 20000000000000002
>
> would loop forever.
>
> After patch application, seq with the above example would print
> '2e+16' once and then exit.
>
> [...]
>
> @@ -88,6 +90,8 @@
>   for(j=0; buf[j]==' '; j++)
>   buf[j] ='0';
>   write(1, buf, n);
> + if(val == max)
> + break;

This isn't quite right. There are many cases where the
precision of any one of the values in {min, incr, max}
will not be enough to make progress in the loop body.
You need something like:

	/* ensure adequate precision of loop invariants */
	if(incr > 0 && (max+incr <= max || min+incr <= min))
		sysfatal("increment is too small");
	if(incr < 0 && (max+incr >= max || min+incr >= min))
		sysfatal("increment is too small");

before going into the loop.

And that's just off the top of my head. I'd need to do
more testing to be confident. Floating point can be
nasty.

But really, if you're playing games at the boundaries
of floating point precision, you're bound to lose. I
suggest we either a) do nothing and leave the loop
exactly as it is described in the manual but add a note
in the BUGS section, or b) go back to the v8 method
that calculates the number of steps in the loop before
executing it. Even with the latter method you can see
odd results due to precision limitations but at least
there will be no infinite loops.

I vote for "a".

Cheers,
  Anthony