News for hackers. Stuff that matters.
Re:Misconceptions about loops in C by anamax on Thursday June 27, 2024 @10:51PM (#40817282)
> For example you can no longer rely on the loop condition being false on loop termination. Instead you have to do a flow analysis of every loop and conditional leading to the break to determine the established postcondition.

I rarely write loops where the relationship between the loop control variables has anything meaningful to say about what the iterations did.

Re:Misconceptions about loops in C by zelphirkalt on Friday June 28, 2024 @03:32AM (#40818520)
Simple example: Get input from the user until the input matches a condition, often "is it a number?".
Re:Misconceptions about loops in C by User23 on Friday June 28, 2024 @12:24PM (#40822214)
Even if that’s true (and you may be more often than you realize), you still rely on a great deal of code that does, like searching and sorting.

It is a little disappointing how few programmers know how to construct a nontrivial loop that both always terminates and does what it’s supposed to for all inputs.

Binary search is a classic example. If you think it’s trivial to get right, you probably aren’t. Knuth has some interesting things to say about it in The Art of Computer Programming.

Re:Misconceptions about loops in C by anamax on Saturday June 29, 2024 @01:52AM (#40828169)
Binary search is a great example of why you can't just look at the loop control variables to understand what body does for the iterations.

You have to look at both. If it turns out that the body's behavior can be easily described in terms of the loop control variables (or the reverse), great, but assuming that it does and trying to fix up things when that gets complicated is a disaster.

Of course, if you dislike break, you can fake it with continue and a flag, as long as your loop control guarantees termination. However, that complicates understanding the loop's behavior in terms of said control.