From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 4948 invoked from network); 16 Aug 2021 23:40:17 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 16 Aug 2021 23:40:17 -0000
Received: from MTA-11-3.privateemail.com ([198.54.122.105]) by 1ess; Mon Aug 16 18:24:48 -0400 2021
Received: from mta-11.privateemail.com (localhost [127.0.0.1])
	by mta-11.privateemail.com (Postfix) with ESMTP id B8A3B18000AA;
	Mon, 16 Aug 2021 18:24:37 -0400 (EDT)
Received: from localhost (unknown [10.20.151.236])
	by mta-11.privateemail.com (Postfix) with ESMTPA id 0EE9418000A0;
	Mon, 16 Aug 2021 18:24:37 -0400 (EDT)
Date: Mon, 16 Aug 2021 15:24:29 -0700
From: Anthony Martin <ality@pbrane.org>
To: 9front@9front.org
Cc: nabijaczleweli@nabijaczleweli.xyz
Message-ID: <YRrlnTa3XgX1bb1o@alice>
References: <CADmmOS-wcgtcQ+=c01NvssHO3=06zbQjU6NzLt_K0eOX4OQe=w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CADmmOS-wcgtcQ+=c01NvssHO3=06zbQjU6NzLt_K0eOX4OQe=w@mail.gmail.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Content-Transfer-Encoding: quoted-printable
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: generic engine enhancement deep-learning controller 
Subject: [9front] Re: seq: fix infinite loop
Reply-To: 9front@9front.org
Precedence: bulk

Sean Hinchee <henesy.dev@gmail.com> once said:
> =D0=BD=D0=B0=D0=B1 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=3D0; buf[j]=3D=3D' '; j++)
>   buf[j] =3D'0';
>   write(1, buf, n);
> + if(val =3D=3D 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 <=3D max || min+incr <=3D min))
		sysfatal("increment is too small");
	if(incr < 0 && (max+incr >=3D max || min+incr >=3D 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