In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended
in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

I've applied this method in many C and (vaguely) C-like languages.
Any language with a "for" type loop, where you can check the value after
the loop can avail themselves of this method.

--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended
in order to determine if the loop ended "normally" or prematurely via "break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

I've applied this method in many C and (vaguely) C-like languages.
Any language with a "for" type loop, where you can check the value after
the loop can avail themselves of this method.

I concur :-)

--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vtrvc6$mjoi$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
...

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

Indeed. This is the common case - where you are looking for something, and
if you find it, you break out of the loop (one way or another). If you
don't find it, then the loop terminates "normally" - and you need to catch
that case.

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

Bart won't like the way you've abused C's "for" statement syntax to your
own devious ends...

(But I like it)
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seneca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 23:29, Lew Pitcher wrote:

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended >> in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

This seems an unnecessarily complicated loop. Even in C, it could be
written more cleanly.

There is no 'end-of-list marker' that I can see; it is a straight linear search:

n = -1;
for (i = 0; i < NUM_ENTRIES; ++i)
if (node[i] == key) { n = i; break;}

Now the loop header is a 100% routine iteration. Or, to avoid an
auxiliary index (and still use -1 as the error marker rather than
NUM_ENTRIES):

for (n = NUM_ENTRIES-1; n >= 0; --n)
if (node[n] == key) break;

BTW your example seems to have a bounds error (I assume the top element
is at index NUM_ENTRIES-1). With a more complex approach approach, that
is harder to spot.

(Below is how it might work in my language by utilising an 'else' part
to the loop, here used to detect a key-not-found rather than key-found.)

for i to node.len do
exit when node[i] = key
else
println "Key not found"
end

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-17, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended >> in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

You're saying that the number of entries in the array isn't
NUM_ENTRIES but NUM_ENTRIES + 1, since you're accessing node[0]
and node[NUM_ENTRIES]

Don't you want:

for (n = NUM_ENTRIES - 1; ...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.04.2025 00:29, Lew Pitcher wrote:

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended >> in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

In "C" (and with low-level "C" arrays starting at 0) I find iterations
always a bit crude _if started from the end_. Anyway.

I'd like to remind another standard method (just for good measure)...

Adding the searched element at the end of the array - where you have
to _take provisions that there is storage_, of course - like

node[N] = key;
for (i=0; node[i] != key; i++)
// ...whatever...
if (i==N) // ...not found...
else // ...found at i...

with the nice property to have just one test to perform in the loop.

Janis

I've applied this method in many C and (vaguely) C-like languages.
Any language with a "for" type loop, where you can check the value after
the loop can avail themselves of this method.

I concur :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 16:24, Kaz Kylheku wrote:

On 2025-04-17, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended >>> in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

You're saying that the number of entries in the array isn't
NUM_ENTRIES but NUM_ENTRIES + 1, since you're accessing node[0]
and node[NUM_ENTRIES]

Don't you want:

for (n = NUM_ENTRIES - 1; ...

That looks like another inconsistency in the syntax (and another error opportunity).

Since the loop for upward and downward iterations between 0 and N-1
inclusve would be:

for (i = 0; i < N; ++i)
for (i = N-1; i >= 0; --i)

'N-1' is what I would have to write; it's odd that C people have write
it too. Unless perhaps you do this:

for (i = N; i-- > 0;)

Here you now have a genuine 2-part loop!

I guess this is C being 'flexible', in being able to reinvent for-loops
each time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 18 Apr 2025 15:24:49 +0000, Kaz Kylheku wrote:

On 2025-04-17, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended >>> in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

You're saying that the number of entries in the array isn't
NUM_ENTRIES but NUM_ENTRIES + 1, since you're accessing node[0]
and node[NUM_ENTRIES]

Don't you want:

for (n = NUM_ENTRIES - 1; ...

Yes, thanks, Kaz

It wasn't a quote from working code, but an off-the cuff paraphrase
of a number of different loops that I've written at various times.
In hindsighe, I probably should have named that macro
LAST_ENTRY
instead of
NUM_ENTRIES




--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 17/04/2025 23:29, Lew Pitcher wrote:

On Thu, 17 Apr 2025 21:21:54 +0000, Kenny McCormack wrote:

In article <87fri68w2c.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...

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.

I frequently check the value of the loop variable after the loop has ended >>> in order to determine if the loop ended "normally" or prematurely via
"break". E.g.,

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

Kenny McCormack wrote:

Bart won't like the way you've abused C's "for" statement syntax to your >>own devious ends...

This seems an unnecessarily complicated loop. Even in C, it could be
written more cleanly.

Point to Kenny.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.04.2025 17:57, bart wrote:

On 18/04/2025 16:24, Kaz Kylheku wrote:

On 2025-04-17, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

[...]

[...]
for (n = NUM_ENTRIES - 1; ...

That looks like another inconsistency in the syntax (and another error opportunity).

Since the loop for upward and downward iterations between 0 and N-1
inclusve would be:

for (i = 0; i < N; ++i)
for (i = N-1; i >= 0; --i)

'N-1' is what I would have to write; it's odd that C people have write
it too. Unless perhaps you do this:

for (i = N; i-- > 0;)

Here you now have a genuine 2-part loop!

I guess this is C being 'flexible', in being able to reinvent for-loops
each time.

It is perfectly fine to write your loops in "C" as

for (i = 1; i <= N; ++i)
for (i = N; i >= 1; --i)

(and access your array elements as [i-1] if you wish).

You should be aware that the problem you have here is *not* a "C" "loop-problem", it's a problem of the low-level _"C" arrays_ you
have to use; they force you to define and use bounds of 0 and N-1
respectively if you want to use an array of N elements.

Try to address the issues to the correct source of "C" constructs.
The loop flexibility allows you to address such "array-crudeness",
it is not the source of the problem, neither here nor generally.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 17:46, Janis Papanagnou wrote:

On 18.04.2025 17:57, bart wrote:

On 18/04/2025 16:24, Kaz Kylheku wrote:

On 2025-04-17, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

[...]

[...]
for (n = NUM_ENTRIES - 1; ...

That looks like another inconsistency in the syntax (and another error
opportunity).

Since the loop for upward and downward iterations between 0 and N-1
inclusve would be:

for (i = 0; i < N; ++i)
for (i = N-1; i >= 0; --i)

'N-1' is what I would have to write; it's odd that C people have write
it too. Unless perhaps you do this:

for (i = N; i-- > 0;)

Here you now have a genuine 2-part loop!

I guess this is C being 'flexible', in being able to reinvent for-loops
each time.

It is perfectly fine to write your loops in "C" as

for (i = 1; i <= N; ++i)
for (i = N; i >= 1; --i)

(and access your array elements as [i-1] if you wish).

That's never going to happen. Only, possibly, if you have to port a
1-based algorithm to C, without risking the bugs that will creep in if
you try and convert it to 0-based.

Sure, with 1-based, upward and downward counting loops can be more
symmetrical.

You should be aware that the problem you have here is *not* a "C" "loop-problem", it's a problem of the low-level _"C" arrays_ you
have to use; they force you to define and use bounds of 0 and N-1 respectively if you want to use an array of N elements.

I can use 0-base arrays in my language, and yes, for loops to iterate
over bounds could involve 0 and N-1:

for i 0 .. N-1 do

but they can also look like this:

for i in A.lwb .. A.upb do

or just:

for i in A.bounds do
for i, x in A do # iterate over bounds and values

'0' and 'N-1' or 'A.len-1', don't appear at all.

So while 0-based can be more troublesome, it can still be a language
problem rather a 0-based one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 18 Apr 2025 13:58:08 +0000, Kenny McCormack wrote:

In article <vtrvc6$mjoi$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
...

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

Indeed. This is the common case - where you are looking for something, and if you find it, you break out of the loop (one way or another). If you
don't find it, then the loop terminates "normally" - and you need to catch that case.

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

Bart won't like the way you've abused C's "for" statement syntax

I've long since stopped caring what Bart does or doesn't like. :-)

to your own devious ends...

I'll give you another devious one :-)

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
double nc;

for (nc = 0; getchar() != EOF; ++nc)
;

printf("%.0f\n",nc);

return 0;
}

(transcribed and updated for modern C from a 1978 edition of
"The C Programming Language" by Kernighan and Ritchie)

(But I like it)

As do I. It is succinct, complies with the syntax of the C language,
and achieves the desired algorithmic goal.

--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 19:33, Lew Pitcher wrote:

On Fri, 18 Apr 2025 13:58:08 +0000, Kenny McCormack wrote:

In article <vtrvc6$mjoi$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
...

for (i=0; i<10; i++) { code that might or might not break }
if (i == 10) puts("It ended normally");

It's also a handy idiom for a compact list search loop
where the terminating condition is either end of the list, or
a matched entry.
If the cursor isn't the end-of-list marker, then it references
the matched entry;

Indeed. This is the common case - where you are looking for something, and >> if you find it, you break out of the loop (one way or another). If you
don't find it, then the loop terminates "normally" - and you need to catch >> that case.

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;
if (n != -1) printf("Found key at entry %d\n",n);

Bart won't like the way you've abused C's "for" statement syntax

I've long since stopped caring what Bart does or doesn't like. :-)

That's fine. It's been far longer that I've given up caring what people
think of my generated C code

(They used to like turning up the warnings high enough for it to fail.
Clearly that defined but unused label is a critical error.)

to your own devious ends...

I'll give you another devious one :-)

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
double nc;

for (nc = 0; getchar() != EOF; ++nc)
;

printf("%.0f\n",nc);

I'll give you this one. Finally something that is impossible to achieve
with a simple and far more appropriate 'while':

double nc;

nc = 0;
while (getchar() != EOF) ++nc;

printf("%.0f\n",nc);

As do I. It is succinct, complies with the syntax of the C language,
and achieves the desired algorithmic goal.

That's a pretty low bar. You can say the same about any of my generated, low-level C code, which is pretty much unreadable by any human.

It's odd how some here have standards which stops them even declaring
three related variables on the same line:

double x, y, z; // fails guidelines

But cramming as much crap as possible into a FOR-loop header, for no
reason other than because you can, seems to be condoned.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.04.2025 19:40, bart wrote:

On 18/04/2025 17:46, Janis Papanagnou wrote:

On 18.04.2025 17:57, bart wrote:

On 18/04/2025 16:24, Kaz Kylheku wrote:

On 2025-04-17, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

[...]

[...]
for (n = NUM_ENTRIES - 1; ...

That looks like another inconsistency in the syntax (and another error
opportunity).

Since the loop for upward and downward iterations between 0 and N-1
inclusve would be:

for (i = 0; i < N; ++i)
for (i = N-1; i >= 0; --i)

'N-1' is what I would have to write; it's odd that C people have write
it too. Unless perhaps you do this:

for (i = N; i-- > 0;)

Here you now have a genuine 2-part loop!

I guess this is C being 'flexible', in being able to reinvent for-loops
each time.

It is perfectly fine to write your loops in "C" as

for (i = 1; i <= N; ++i)
for (i = N; i >= 1; --i)

(and access your array elements as [i-1] if you wish).

That's never going to happen.

Yes, I also think that people prefer to adjust the loop interval
in _one place_ (the 'for' loop) than to adjust it in every place
of array access. And so there's the usual transformations applied,

for (i = 1; i <= N; ++i) a[i-1]
for (i = 0; i <= N-1; ++i) a[i]
for (i = 0; i < N; ++i) a[i]

for (i = N; i >= 1; --i) a[i-1]
for (i = N-1; i >= 0; --i) a[i]

Only, possibly, if you have to port a
1-based algorithm to C, without risking the bugs that will creep in if
you try and convert it to 0-based.

But "C" is (standard) "C", and not something home-brew.

Sure, with 1-based, upward and downward counting loops can be more symmetrical.

And you've also understood the point where the problem is really is?

You should be aware that the problem you have here is *not* a "C"
"loop-problem", it's a problem of the low-level _"C" arrays_ you
have to use; they force you to define and use bounds of 0 and N-1
respectively if you want to use an array of N elements.

I can use 0-base arrays in my language, [...]

(I'm not interested in any proprietary software.)

So while 0-based can be more troublesome, it can still be a language
problem rather a 0-based one.

But it isn't, as shown.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 18 Apr 2025 16:07:03 +0100, bart wrote:

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

using goto label would be as this

n=NUM_ENTRIES
L: if(!((n >= 0) && (node[n] != key))) goto Ex
--n; goto L;
Ex:

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24.04.2025 22:43, Rosario19 wrote:

On Fri, 18 Apr 2025 16:07:03 +0100, bart wrote:

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

using goto label would be as this

n=NUM_ENTRIES
L: if(!((n >= 0) && (node[n] != key))) goto Ex
--n; goto L;
Ex:

You are just showing a low-level transformation of a higher-level
construct. (I'm sure the professional folks here are familiar with
such transformations.)

You are not [seriously] suggesting to use that 'goto' based form
instead of the 'for' loop, do you?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/04/2025 06:50, Janis Papanagnou wrote:

On 24.04.2025 22:43, Rosario19 wrote:

On Fri, 18 Apr 2025 16:07:03 +0100, bart wrote:

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

using goto label would be as this

n=NUM_ENTRIES
L: if(!((n >= 0) && (node[n] != key))) goto Ex
--n; goto L;
Ex:

You are just showing a low-level transformation of a higher-level
construct. (I'm sure the professional folks here are familiar with
such transformations.)

You are not [seriously] suggesting to use that 'goto' based form
instead of the 'for' loop, do you?

That's exactly the kind of thing that should be considered harmful.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 24 Apr 2025 22:43:32 +0200, Rosario19 wrote:

On Fri, 18 Apr 2025 16:07:03 +0100, bart wrote:

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

using goto label would be as this

n=NUM_ENTRIES
L: if(!((n >= 0) && (node[n] != key))) goto Ex
--n; goto L;
Ex:

n=NUM_ENTRIES
L: if(n<0 || node[n]==key)goto Ex; --n; goto L;
Ex:

this is more clear of above... yes if one is accostumated to use
for(;;) loop this would be better

for(n=NUM_ENTRIES;n>=0 && node[n]!=key; --n);

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 25 Apr 2025 10:38:03 +0200, Rosario19 <Ros@invalid.invalid>
wrote:

for (n = NUM_ENTRIES; (n >= 0) && (node[n] != key); --n) continue;

this code has a bug if array "node" has lenght less or ugual to
NUM_ENTRIES, so the lenght of "node" has to be at last NUM_ENTRIES+1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)