Loops, from the beginning

1 · The problem loops exist to solve

Print "Hello" five times, with what you have from Labs 1–3, and you write printf five times. It works. Now print it ten thousand times. Now print it a number of times the user chooses — a number you don't know when you're writing the program, because it doesn't exist yet.

That last one is the real wall. You cannot copy and paste a line a number of times that isn't known yet. What you need is a way to say something you have never said to a computer before:

Here is the mechanism, and it is smaller than you'd expect. A loop is a condition and a block of code, wired together in a cycle:

1. Check the condition. Is it true?
2. If yes: run the block, then go back to step 1.
3. If no: skip the block and carry on with the rest of the program.

That's it. Everything in this lab — five kinds of loop syntax, nested loops, break, patterns, prime tests — is that cycle with different things filled in. Notice what has to be true for the cycle ever to end: something inside the block must change something the condition looks at. If not, the answer at step 1 never changes, and the program runs until you kill it. That single sentence explains half the bugs in this lab.

2 · Counting, and the ++ that does it

Loops count constantly, so C gives you three ways to write "add one to count", each shorter than the last:

count = count + 1;   // the long way — nothing wrong with it
count += 1;          // compound assignment
count++;             // the increment operator

All three do exactly the same thing when they sit alone on a line. -- is the same story for subtracting one. And += generalises: sum += d means sum = sum + d, which is the shape of every accumulator you will write.

There is one wrinkle the lab sheet raises, and it matters only in a specific situation. You can write count++ (postfix) or ++count (prefix). The difference appears only when the increment is inside a bigger expression:

int a = 5;
int b = a++;   // POSTfix: b takes the OLD value (5), then a becomes 6
// a = 6, b = 5

int x = 5;
int y = ++x;   // PREfix: x becomes 6 FIRST, then y takes the new value
// x = 6, y = 6

a=6, b=5
x=6, y=6

Remember it by reading the position of the ++ as when it happens: after the variable means afterwards, before the variable means beforehand. In a loop header like for (int i = 0; i < 5; i++) the update stands on its own, so i++ and ++i behave identically — use whichever, and don't lose time over it.

3 · The while loop, built slowly

The simplest loop is the cycle written literally. "Keep going while this is true":

while (condition) {
    // statements to repeat
}

Print "Hello" five times. Build it from the three questions rather than copying it:

1. What is the state? We need to know how many we've printed. Call it count, starting at 0 — nothing printed yet.
2. What keeps it going? count < 5. Fewer than five printed so far, so print another.
3. What advances? count++ after each print — otherwise count stays 0 forever and so does the answer to question 2.

int count = 0;             // 1. initialisation

while (count < 5) {        // 2. condition
    printf("Hello\n");
    count++;               // 3. update
}

Now the part that separates people who can write loops from people who can only recognise them: trace it. On paper, one row per pass, one column per variable. Never hold two numbers in your head at once.

Five Hellos, and count ends at 5, not 4 — because the last thing the loop does is fail the test, and it has to reach 5 to fail it. That "one past the end" feeling is normal and it is where off-by-one errors are born. Tracing is how you catch them; there is no substitute, and every good programmer still does it.

A loop that runs zero times

A while tests before the body, so if the condition is false at the start, the body never runs at all:

int count = 10;
while (count < 5) {      // false immediately
    printf("Hello\n");   // never happens
    count++;
}

This is not an error. It is a feature you will rely on — and it is the boundary case §19 of the sheet keeps pointing at. The digit-extraction loop while (temp != 0) runs zero times when the input is 0, which is why a naive digit counter says the number 0 has zero digits. Examiners like that question precisely because it looks like a trick and isn't: it's just the definition of while being applied honestly.

4 · do-while, for when it must happen at least once

Sometimes you can't test first, because the thing you'd test doesn't exist yet. Asking the user for a positive number: you cannot check whether their answer is positive before they have answered. So the test moves to the bottom:

int choice;
do {
    printf("Enter a positive number: ");
    scanf("%d", &choice);
} while (choice <= 0);   // note the semicolon

Read it as "do this … while that stays true". The prompt always appears at least once; if they type −4, the condition is true and round we go again. That is the whole difference between while and do-while, and it is worth being able to say in one sentence, because it is asked in one sentence:

Use do-while for input validation, menus, and "keep asking until they get it right" — which is Problem 4, the PIN validator. Everywhere else, while or for reads better.

5 · The for loop, and exactly what it does when

Look back at the Hello loop and notice that its three parts were scattered: initialisation above the loop, condition in the header, update buried at the bottom of the body. In a long body, the update is easy to lose — and losing it is the infinite-loop bug. So C offers a shape that puts all three where you can see them at once:

for (initialisation; condition; update) {
    // body
}

for (int i = 0; i < 5; i++) {
    printf("Hello\n");
}

This is the same loop as the while version — same five Hellos, same values. Nothing new happens; the three parts just moved onto one line where a reader can check them in a glance. That's the only reason for exists.

What you do need to know exactly is the order things happen in, because most trace questions are really questions about this order:

In words, and worth memorising as a list of five:

1. Run the initialisation — once only, ever.
2. Test the condition. False? Leave the loop immediately.
3. Run the body.
4. Run the update.
5. Go back to step 2.

Two consequences fall straight out. The body sees i = 0 on the first pass (the update hasn't happened yet), and the loop variable ends up one past the last value the body saw. And a for loop, like a while, can run zero times — for (int i = 0; i < 0; i++) tests, fails, and does nothing.

The three slots don't have to hold counting-by-one. Any expression works, and this is worth seeing once so it doesn't surprise you in a question:

for (int i = 10; i >= 1; i--)          // count down
for (int i = 2; i <= n; i += 2)        // step by two — even numbers only
for (int i = 5; i < 200 && keepGoing; i *= 2)   // double, with an extra condition

for (int i = 1; i <= 4; i++)
    printf("%d", i);
    printf("|");     // looks inside; is NOT inside

6 · Which loop should I use?

Any loop can be rewritten as any other, so this is a readability choice — but it is a marked one, and the right answer is usually obvious from how the problem is phrased:

7 · Loops inside loops

Put a loop in another loop's body and something genuinely new becomes possible: two dimensions. The rule is one sentence — for every single pass of the outer loop, the inner loop runs all the way through — and the consequence is that the inner loop's counter restarts every time.

for (int i = 1; i <= 3; i++) {          // outer
    for (int j = 1; j <= 2; j++) {      // inner
        printf("i=%d, j=%d\n", i, j);
    }
}

i=1, j=1
i=1, j=2
i=2, j=1
i=2, j=2
i=3, j=1
i=3, j=2

Six lines from 3 × 2 — the inner loop's two passes happen inside each of the outer loop's three. The mental picture that makes patterns easy is a grid: the outer loop is the rows, the inner loop is the columns of one row, and the printf("\n") that ends a row belongs after the inner loop, inside the outer:

int n = 5;
for (int i = 1; i <= n; i++) {          // rows
    for (int j = 1; j <= i; j++) {      // columns: as many as the row number
        printf("*");
    }
    printf("\n");                       // end this row
}

*
**
***
****
*****

8 · Escaping early: break and continue

Two statements bend the cycle from inside the body.

break abandons the loop entirely. Not just this pass — the whole loop. Execution continues after the closing brace:

for (int i = 1; i <= 10; i++) {
    if (i == 5) break;
    printf("%d ", i);
}
// Output: 1 2 3 4

continue abandons only the current pass and jumps ahead to the update and the next test:

for (int i = 1; i <= 5; i++) {
    if (i == 3) continue;
    printf("%d ", i);
}
// Output: 1 2 4 5

Read both examples by walking the body top to bottom: on the pass where the if fires, the printf below it is never reached, which is why 5 and 3 are missing from their outputs.

Neither is required: a well-chosen condition often removes the need for both. But break is genuinely natural for "stop as soon as you find it" — which is why the sheet's prime check and Problem 5's guesser both use one.

9 · The three ways loops go wrong

Not a list to memorise — three stories, each with a symptom you can recognise in the exam hall.

The infinite loop: nothing advances

int x = 5;
while (x > 0) {
    printf("%d\n", x);
    // missing: x--;
}

Symptom: output pours out forever, or the program just sits there. Cause: the condition looks at x and nothing in the body changes x. Cure: Ctrl+C to kill it, then ask question 3 — how does this advance?

The off-by-one: the boundary is one out

for (int i = 1; i < 10; i++)   // wanted 1 to 10; stops at 9

Symptom: one line too few, or one too many. Cure: don't nudge the +1 until it looks right — count the values the variable actually takes. From 1 with i < 10: 1…9, nine passes. With i <= 10: 1…10, ten.

The uninitialised accumulator: adding to garbage

int sum;                       // contains whatever was in that memory
for (int i = 1; i <= 5; i++) sum = sum + i;

Symptom: a huge, arbitrary number — running this printed 221908503 on the machine these notes were written on, and it may differ on yours. Cause: C does not zero your variables; you get whatever bytes were lying there. Cure: int sum = 0; — and compile with -Wall, which warns you before you ever see the number.

10 · Attacking a problem you haven't seen

This is the actual skill being examined, and it is a routine, not an inspiration. Take: "Read a positive integer and print how many digits it has."

1. Write the required output on your paper first. One line: Digits: 3. Now you know what "finished" looks like.
2. Ask the three questions.
   • State: the number as it shrinks (call it temp, starting at n), and a counter starting at 0.
   • Stop: when there is nothing left of the number — temp != 0 keeps it going.
   • Advance: remove one digit — temp /= 10.
3. Choose the shape. The digit count is unknown before we start, so: while.
4. Trace two passes on a small input before writing anything. For 452: temp 452 → 45 → 4 → 0, with digits 1 → 2 → 3. It works on paper, so it will work in C.
5. Type it, compile early.

   int digits = 0, temp = n;
   while (temp != 0) {
       digits++;
       temp /= 10;
   }
   printf("Digits: %d\n", digits);

6. Test the boundaries: zero iterations (input 0 → prints 0, arguably wrong — mention it), one iteration (input 7 → 1), typical (452 → 3).

Steps 1, 2 and 4 happen away from the keyboard, and they are where the marks are. Students who start typing at step 5 spend the session debugging; two minutes of tracing prevents twenty minutes of it.

11 · Testing a loop properly

§19 of the lab sheet asks for representative test cases, and it is asking for four specific ones. Write them down before you write the loop:

Volunteering these in a lab evaluation is worth marks even when the program isn't perfect, because designing tests is explicitly one of the learning outcomes on the sheet. Write them as a comment at the top of your file: /* tested: n=0 → 0 digits; n=7 → 1; n=452 → 3 */.

Where to go next

You now have the whole mechanism. The rest is repetition in the literal sense — writing loops until the three questions answer themselves.

• Lab 4 solutions — all seven practice problems, the five debugging exercises and the four dry runs, each worked with a trace and verified output. Start with Problem 1.
• Loops notes — the compressed map: the ten patterns, the trap list, the practice table. This is the page to have open during an open-book lab evaluation.
• Hanly & Koffman, chapter 5 — the textbook chapter this lab covers, and the self-check exercises at the end of each section.