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

bart <bc@freeuk.com> writes:

On 17/04/2025 03:18, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

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.

Whereas for a language like C which is defined by a written
standard,
the standard *must* specify the behavior at the language level
(not in terms of generated intermediate or machine code).

>
At the language level, the behaviour of FOR loop variable iterating
over A to B inclusive, simply has the variable assuming each of those
values in turn. It doesn't say how it does that.

Does this refer to your own language?  I thought you said it had issues
when the upper bound is the maximum value of the type.  If that's the
case, then either the language-level description has to describe the
behavior in that case, or you don't have an accurate language-level
description.

However, it becomes more important if the language has anything to say
about the value of the loop variable after the loop terminates (when
its scope is not limited to the loop body as is the case in my
language).
>
Then the value might be B + step or B - step, depending on which way
it iterates, using the current implementation.

C doesn't cover that explicitly because it doesn't need to.  Formally,
there's no such thing as a "loop variable".

Ada doesn't need to, because the loop variable is local to the loop (and
read-only within it).

Pascal says the value of the control variable is undefined after the
loop.

IMHO it doesn't much matter what the value is after the loop ends, but
any standard for a language with such a feature should either restrict
the scope to the loop, specify the value the variable has after the
loop, or explicitly say that it's unspecified or undefined.

The fact that
     for (int i = INT_MAX-1; i <= INT_MAX; i++);
has undefined behavior can be rigorously inferred from the language
definition.
 

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.

You know, of course, that C's int type is not necessarily 32 bits.
There is no "default" for the width of int.  If you had written "with
32-bit int", that would have been clear and correct.

>
I think it's perfectly reasonable for such discussions to assume 'int'
is 32 bits. And to only qualify it only when it can matter.

I don't.

For computers in general, that assumption is likely to have held for
at least 20 years, possible even 30.
>
Or maybe you can tell me where I can buy a computer (not some board
with an embedded microcontroller) where a C compiler for it has an
'int' type other than 32 bits (with either fewer bits, or more!).

Not the point.  It's about what "int" *means*.  It doesn't mean "a
32-bit integer".

At present it only seems to bother you. Since if it REALLY bothered
anyone here, nobody would be using 'int'; they'd be using int32_t or
long, unless they're happy that their int values and intermediate
calculations would be using only 16 bits.

POSIX and Windows both guarantee that int is at least 32 bits wide, and
it's perfectly reasonable to rely on those guarantees on those platforms.

It would be so easy for you to get this right, but you don't even
acknowledge the possibility that I might have a valid point.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */