Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Thu, 17 Apr 2025 11:47:07 -0700
Organization: None to speak of
Lines: 89
Message-ID: <87fri68w2c.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$1@dont-email.me> <20250413072027.219@kylheku.com>
	<vtgpce$39229$1@dont-email.me> <vti2ki$g23v$1@dont-email.me>
	<vtin99$vu24$1@dont-email.me> <vtiuf0$18au8$1@dont-email.me>
	<vtj97r$1i3v3$1@dont-email.me> <vtl166$36p6b$1@dont-email.me>
	<vtlcg0$3f46a$2@dont-email.me> <20250415053852.166@kylheku.com>
	<vtm4ae$6d5j$1@dont-email.me> <H7yLP.2056536$OrR5.1414451@fx18.iad>
	<vtmgj8$g81k$1@dont-email.me> <vtnfjj$1gk91$1@dont-email.me>
	<vto4fu$23kmr$1@dont-email.me> <20250416142925.663@kylheku.com>
	<vtpbnm$357ma$2@dont-email.me> <20250416164536.110@kylheku.com>
	<vtpj5h$3duft$1@dont-email.me>
	<87ikn3zg18.fsf@nosuchdomain.example.com>
	<vtqnv9$hf83$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 17 Apr 2025 20:47:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ce66778584175375d620efc7d3b77de7";
	logging-data="1331452"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Q7CJMczH5Jds0+Lq62ff6"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:pNMaWmgTvB3qD+iQ75OqhzcBvg0=
	sha1:eVQTi/w3dNiLH7cn9vsw9xVFljI=
Bytes: 5382

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 */