Re: Loops (was Re: do { quit; } else { })

On 17/04/2025 00:49, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

language:
>
     for i in i64.max-10 .. i64.max do println i

 Exactly, small n.
 

which doesn't stop (u64 is OK however).

 What? That's a boogy bug.

(Yeah. Backend problem which hardcoded signed compared. 'for' iteration has its own IL instruction.)

 

That doesn't worry me too much,
I can just add a Note to the language spec warning of UB when a for-loop
bound is at the limits of the type.

 I will frame these words next time you cricize C of taking some
easy way out and shirking doing the Right Thing with UB.

I can make it implementation-defined since the behaviour can be predicted on the targets I will use. But in the language, if the natural wrap on overflow gives unexpected results, then you have a program bug.
I think what you were alluding to was the implicit increment used to implement for-loops. Well this is the IL instruction for FOR that I mentioned above:
   (kforup,    ..), # B+:=n; goto L when B<=C
The increment is part of its behaviour. At the language level, I could explain how FOR is implemented, but I'd rather not do that.
A note that upper and lower limits must be in the range i64.min + s .. i64.max - s (where s is the step size) can suffice.
What's far more useful is that it naturally works with i64 so has limits 4 billion times bigger than you get with C's default 'int' type.

Where all sorts of other stuff can
happen because of how values wrap.

 You can fix all the other stuff at the language level also.

How do you fix overflow of A * B?

Then we can do
>
    for (int i = INT_MIN; : i < INT_MAX; i++)
>
After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.
>

>
You're trying too hard. I don't think the language needs to bother
providing solutions, it just needs to specify the limitations.

 I don't understand why you're not in the C camp with these words.

I am in the C camp (I said exactly that a few days ago). I just don't like the way the visible language was designed, and think there are too many unreasonable UBs.
There are plenty of higher level languages that can deal with this properly (I guess; I haven't tried them).
Although those that have copied C's 'for'-loop syntax are likely to be using the same kind of loop iteration that can cause a problem.
Maybe the language can detect overflow, but it won't help, as you want to loop to stop not abort the program. So it is not a solution.