The Temperature Logger That Skips Readings
A technician writes a program to read a sensor once per second for 60 seconds and store each reading in an array indexed 0 to 59. The loop counter starts at 1 and runs while counter <= 60, storing the reading at position counter. After a test run, the technician notices two symptoms: the final reading is never stored, and the program crashes with an 'index out of bounds' error. The sensor itself is verified working, and the readings collected so far are correct values. A colleague suggests simply enlarging the array to 61 slots as a quick fix.
1. Explain why the program exhibits both symptoms, and identify the exact logical error rather than the symptom.
Read the worked answer
The loop counter runs from 1 to 60 (inclusive), which is 60 iterations, but it writes to positions 1 through 60. Position 0 is never written (so the first slot holds a default/empty value, and the reading that should have gone there is lost), and position 60 does not exist in an array of size 60, causing the out-of-bounds crash.
The logical error is an off-by-one / index-base mismatch: the counter was designed as a 1-based count but used directly as a 0-based array index. The crash is only a symptom; the real defect is the mismatch between the counting convention and the indexing convention.
Correct fix: either loop for i in 0..59 and store at i, or loop for counter in 1..60 and store at counter - 1. This both stores all 60 readings and stays in bounds.
2. Evaluate the colleague's suggestion of enlarging the array to 61 slots. Does it fix the problem?
Read the worked answer
No. Enlarging the array to 61 slots only removes the crash by making position 60 valid. It does not fix the logic:
- Position 0 is still never written, so the program still loses one reading and stores garbage/default in slot 0.
- The program now records only 59 real readings plus one unused slot, so the data set is silently incomplete.
This is a classic symptom patch: it suppresses the visible failure (the crash) while leaving the underlying defect, which makes the bug harder to find later. The correct action is to fix the index arithmetic, not the container size. Enlarging the array would be legitimate only if the requirement genuinely called for 61 slots.
3. The technician wants to add a check so this class of bug is caught automatically in future. Describe what to test and why.
Read the worked answer
Test the boundaries, not just the middle of the range:
- Verify the number of stored readings equals exactly 60 after a full run.
- Verify the first element (index 0) contains the first sensor reading and the last element (index 59) contains the 60th reading.
- Assert that no write ever targets an index outside 0..59 (e.g., a guard or assertion in the store routine).
Boundary testing is the right tool because off-by-one errors live precisely at the edges (first and last iteration), where ordinary 'does it run' testing passes. A test that only checks a middle reading would have missed both symptoms.