Code Investigation Lab

Programming FoundationsLab 3 of 3 · Investigative90–120 minutesLabBuilds on: Reading Unfamiliar Code

Hands-on lab

Mission

You’ve practiced reading unfamiliar code, and now you’re going to run the whole loop on one small C program you’ve never seen before. So map its structure, predict what it prints before you run it, trace four records through its functions, test a single boundary change, and then back your conclusion with both the source and the program’s own output. No debugger and no guessing here, just careful reading and controlled tests.

Prerequisites, environment, and boundary

Finish every Programming Foundations lesson and both of the earlier programming labs before you start. Work in the Ubuntu 24.04.4 LTS x86-64 course VM, with GCC 13.x.

The supplied source is the entire target here. Keep it unchanged until the modification milestone, and work only on a copy once you get that far (the original is your reference). This lab is assessing source reading and controlled testing (not speed, and not tooling).

Verify and extract

Download code-investigation-v2.0.0.tar to ~/underdunn-course/downloads.

cd ~/underdunn-course/downloads
sha256sum code-investigation-v2.0.0.tar

Expected digest:

075c2d628928ce15487b2ba00eec3927a3c5a5ff184bb1f5d92fd54649ca3a95  code-investigation-v2.0.0.tar

Extract and verify the internal source identity:

mkdir -p ~/underdunn-course/labs/code-investigation
tar -xf code-investigation-v2.0.0.tar -C ~/underdunn-course/labs/code-investigation
cd ~/underdunn-course/labs/code-investigation/code-investigation-v2.0.0
sha256sum -c CHECKSUMS.sha256

Milestone 1: map before running

Before you run anything, I’d build a map of the program from the source alone, using the same read-before-you-run habit from the last lesson. Read investigate.c and find:

• Constant and its value.
• Enum states.
• Structure fields.
• Functions and their argument/return contracts.
• Data array and element count expression.
• Call graph beginning at main.

But don’t run the program yet, however tempting it looks by now.

Milestone 2: predict every row

Follow each supplied record through the deciding condition. You can use a scratch table if it helps.

Then predict all three summary counts. And treat the value sitting exactly on INSPECT_THRESHOLD as a boundary case in its own right, because it distinguishes >= from >.

Milestone 3: build and compare

gcc -std=c11 -Wall -Wextra -Wpedantic -O0 -g investigate.c -o investigate
./investigate
printf 'status=%s\n' "$?"

The build should emit no warnings at all, and the status should come back as zero. Compare the printed classifications with the conditions you followed. If one of them differs, find the first source condition where your trace diverged, and do it before you change anything.

Milestone 4: test one boundary change

Copy the source and change only INSPECT_THRESHOLD from 10 to 13:

cp investigate.c investigate-threshold-13.c

Predict which records and which summary counts are going to change, and then build and run the copy:

gcc -std=c11 -Wall -Wextra -Wpedantic -O0 -g \
  investigate-threshold-13.c -o investigate-threshold-13
./investigate-threshold-13
diff -u investigate.c investigate-threshold-13.c

That diff has to show the threshold constant and nothing else at all. Check the changed rows, and then explain why the invalid record comes through completely unaffected.

Milestone 5: check the counts

Enter the original program’s summary counts: the number of records that ended up in each state. Use decimal values.

Check your answers

Enter the values you found. Your answers are checked in this browser without being sent anywhere.

inspect count

watch count

invalid count

Check answers

The checker uses the baseline counts. Comparing the changed threshold shows which classifications depend on that boundary.

Layered hints

Hint 1: begin with the data

Find the four records and the threshold before following any function calls.

Hint 2: trace the boundary

classify tests negative first, then uses >=. A value equal to the threshold enters the inspect state.

Hint 3: verify the summary

Count one enum result per record, then compare those counts with the indexes used in the final printf.

Common failures and recovery

• The archive or internal checksum doesn’t match: delete the affected copy, download or extract it again, and reverify before going further.
• A compiler warning appears: restore the exact baseline and build that, before you reapply a single change.
• You edited a prediction after running: restore the original entry from your notes, and add the revision separately underneath it.
• Several source lines changed at once: discard that copy, copy the baseline again, and edit only the threshold this time.
• A stale binary keeps running: rebuild the named output, and check its timestamp with ls -l.

Check your result

The checker should accept the baseline counts. In the changed build, records that met the old threshold but fall below the new one should become watch. The invalid record should stay invalid. If the results differ, check the threshold constant you changed.

Reset and cleanup

To retry the lab, remove only the extracted copy and keep the verified archive, so you don’t have to download and re-verify the whole thing again:

cd ~/underdunn-course/labs/code-investigation
rm -rf code-investigation-v2.0.0

Then extract a fresh copy from the archive you already have. When you’re finished for good, remove that archive too:

rm -f ~/underdunn-course/downloads/code-investigation-v2.0.0.tar