The Legacy Student-Number Field That Turned Negative
St. Paul's College, Douala, inherited a records program written in 2001. It stores each student number in a single byte declared as signed, and sorts records by numerical value. Student numbers are issued sequentially; the 2024 intake begins at 132. Since registration opened, the admissions clerk reports that students 132 to 190 appear in the register as negative numbers and are printed before students 1 to 20. The programmer says the numbers can simply be 'retyped'. The school expects 400 students by 2027 and also wants to print ID cards with a background colour stored as a hexadecimal code, currently #2F4A6B. The examinations officer is worried because results are matched to student numbers automatically by the program.
1. Convert student number 190 to an 8-bit binary pattern and explain, with working, why the signed program displays it as a negative value.
Read the worked answer
Conversion: 190 = 128 + 32 + 16 + 8 + 4 + 2.
Using place values 128 64 32 16 8 4 2 1, the bits are 1 0 1 1 1 1 1 0, so 190 = 10111110.
Why it is negative: in an 8-bit signed (two's complement) field, the leftmost bit is the sign bit. A 1 there means negative, so patterns 10000000 to 11111111 represent −128 to −1, not 128 to 255. To find the value, invert the bits and add 1: 10111110 → 01000001 + 1 = 01000010 = 66, so the stored pattern is −66.
Consequences: the valid signed range is only −128 to +127. Numbers 128–190 therefore print as −128 to −66, and because a negative number is less than any positive one, they sort before students 1–20. The ID cards and result matching will misidentify exactly the students whose numbers exceed 127.
Key point: nothing is wrong with the arithmetic of 190; the storage format is too narrow and wrongly signed for the numbering scheme. Changing the displayed number is not a fix - the bit interpretation is.
2. Recommend the field change needed for the 2027 intake, justify it with number ranges, and explain why 'simply retyping' the numbers will not work.
Read the worked answer
Range test: an unsigned 8-bit field holds 0–255, which fails once numbers exceed 255 and would fail even at 400 students. A signed 16-bit field holds −32,768 to 32,767, which is adequate but wastes the sign and invites the same confusion. An unsigned 16-bit integer (0–65,535) is the safest standard choice; a 9-bit field (0–511) would technically cover 400 but is not a normal storage unit and leaves little growth. If the number is stored as text for ID cards, it must be a fixed 3-digit or 4-digit string with a validation rule and leading zeros kept consistent.
Migration, not retyping: the existing bytes for 132–190 are the correct bit patterns for those values when read as unsigned. Re-keying '190' into a signed byte either stores the same −66 pattern again or is rejected as out of range. The data type must be altered and the stored patterns re-read as unsigned; then boundary records (127, 128, 190, 255, 256) should be tested to confirm sorting and result matching.
Also required: back up the database before altering the field, re-run the sort and results-matching routines, and change any printed report that assumes two digits. The examinations officer's concern is the real risk: a mismatch between a printed number and a stored number can attach one candidate's results to another.
3. Convert the hexadecimal colour #2F4A6B to denary RGB values, and explain two reasons why hexadecimal is used for such codes.
Read the worked answer
Conversion: each hexadecimal pair is one byte:
- 2F = (2 × 16) + 15 = 32 + 15 = 47
- 4A = (4 × 16) + 10 = 64 + 10 = 74
- 6B = (6 × 16) + 11 = 96 + 11 = 107
So #2F4A6B = RGB(47, 74, 107), a dark blue-grey.
Why hexadecimal:
- Compactness with an exact binary mapping. One hex digit represents exactly four bits, so two digits represent one byte. A colour that needs three denary numbers (47, 74, 107) and separators is written as six hex digits - shorter, and each byte can be read straight from the code without conversion errors.
- Fewer mistakes in technical work. Long binary strings such as
001011110100101001101011are hard to read and transcribe; grouping them into2F 4A 6Breduces misreading. This is the same reason hex is used for MAC addresses and memory dumps.
Link to the case: the program must read the colour as three unsigned bytes, not as a single signed number. If each pair were interpreted as signed, any component above 127 (such as A0 = 160) would become negative and produce an invalid colour - the same class of error as the student-number field.