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

On 2025-04-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-04-16, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

[...]

The key to using the for() statement is to make sure the three
expressions are related appropriately.

>
The observation is valid that the three expressions often fall into a
pattern by which they can be condensed.
>
  for (var = from; var < to; var++)
>
can be expressed by a construct which mentions var ony once,
and omits the operators.
>
You can obtain this with the preprocessor and be reasonably happy.

>
Sure, you *can*, but I wouldn't.

But then you would complain about the unpreprocessed version
being verbose, because it becomes a choice at that point.

For me the raw C-style for loop is clear enough.
>
I could write a macro like:
>
#define ITERATE(var, from, to) for ((var) = (from); (var) < (to); (var)++)
>
but then anyone reading the code has to understand both how C-style
for loops work and how the ITERATE macro works.

Anyone understanding any program has to be prepared to study
numerous definitions, in all categories of definition.

Par for the course.

Does the expansion
use < or <=?  What happens if "to" is INT_MAX?  Did the author of
the macro get everything right?

If they did get it right, then 37 places where it is being used
are consistently also getting it right, assuming those places
intend for ITERATE(a, b, c) to step an integer or pointer value
over the half-open range[b, c). (This aspect of the macro may
be error-prone, but no language construct can read you mind
as to what primary argument value you intended.)

Mostly I just have to worry about two potential issues in
each of those 37 places: (1) are they stepping the correct
variable? E.g. is any inner loop wrongly "hijacking" an outer
loop's variable? and (2) is the half-open range semantics
correct for that situation?

If the 37 loops are open-coded, I have more material to inspect.
There are more ingredients. Four or five different conventions
might easily be identified among the 37.

Here is the crux of the issue: uses of for loop in C follow
certain recognizeable idioms. You have to stare at the loop for
a few seconds to identify which idiom it is using, and is it
getting it right.

Now if someone else finds that such a macro makes things easier for
them, that's fine.  But often, *in my opinion*, such macros make code
harder to read for someone who knows C well.

Also, annoying nonstandard gobbledygook like:

  result_t res = strip_layer_2_header(packet, L2_STRIP_GAUSSIAN);

Gee, why can't they just put everything in one main() function,
which is filled with nothing but vocabulary from Section 7 of
ISO C, Library, instead of changing the language? Nouns and verbs are
language, you know.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca