Sujet : Re: Loops (was Re: do { quit; } else { })
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 19. Apr 2025, 21:55:02
Autres entêtes
Organisation : None to speak of
Message-ID : <87ldrvna6x.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Gnus/5.13 (Gnus v5.13)
bart <
bc@freeuk.com> writes:
[...]
The fact is that people make typos (obviously, not you or JP or SL or
KT!), and here you would really prefer that the compiler could report
them, but with this feature, it often can't.
Of course I make typos.
I haven't mentioned this, but I wrote "<=" rather than the correct
"<" in a C for loop just a few days ago, in a tiny test program.
I made, found, and corrected the error within perhaps a minute.
There was no diagnostic from the compiler. It would have been nice,
I suppose, if there had been.
Having compilers recognize certain patterns in for loops and issuing
warnings for things that appear to be errors is not a bad idea.
For example, if someone writes :
for (int i = 0; i <= N; j ++)
an optional warning would not be unreasonable. (A fatal error would
be unreasonable, since the code might be correct, though probably
too terse.) Note that this error will be flagged unless there
happens to be a "j" in scope, but that could happen in a nested loop.
Likewise if someone writes :
int arr[5];
for (int i = 0; i <= sizeof arr / sizeof arr[0]; i ++)
with a reference to arr[i] in the body of the loop, a warning would
be reasonable. And in fact gcc does issue a warning with "-Wextra"
and "-O1" or higher: "warning: iteration 5 invokes undefined behavior
[-Waggressive-loop-optimizations]".
C-style for loops do introduce the risk of some errors that
are less likely to occur with less flexible forms of for loops.
Speaking for myself, that is (a) a price I'm willing to pay in
return for increased flexibility, (b) manageable by writing code
carefully, which includes following common idioms, and (c) not
something I can do anything about given that the language isn't
going to change any time soon.
Again, I would not object to adding a new kind of for loop,
similar to what you would prefer, and visually distinct from the
existing for loop, in a new version of the C standard. But that's
not likely to happen because there doesn't seem to be much demand
for it (for reasons that I know make you angry), and I don't care
enough to write a proposal. If someone else does write a proposal,
I'll be glad to help out by nitpicking it.
[...]
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */