The Attendance Register That Printed -56
In a Karnataka government school computer lab, a II PUC student writes a C++ program to store each student's attendance days out of 200 in a signed char variable. A student with 200 attendance days prints as -56. The same program stores names in char name[20]; English names print correctly, but Kannada names appear as question marks when typed on the lab's default console code page. The compiler reports no error. The student first tries changing char name[20] to char name[100], and then suggests using unsigned char for attendance and wchar_t for names. The lab has 30 computers running a 32-bit compiler, and the practical exam requires reading values with cin and printing with cout. The teacher asks the student to separate the range problem from the encoding problem and to justify each proposed fix, including what happens if the attendance count later exceeds 255 or if a name contains more than 20 bytes in UTF-8.
1. Explain why 200 stored in a signed char prints as -56, and evaluate the student's proposal to change the type to unsigned char. Include the 8-bit pattern and one input-method problem the student may hit with cin >> days.
Read the worked answer
signed char is an 8-bit two's-complement type with range -128 to 127. Decimal 200 is 11001000 in 8 bits: the sign bit is 1, and the remaining value is 64 + 8 = 72, so the interpreted value is -128 + 72 = -56. unsigned char has range 0 to 255, so 200 fits and prints as 200. That is a valid fix only while attendance stays at or below 255; 256 would wrap to 0, so a count of 300 would still be wrong. More importantly, cin >> days where days is a char extracts one character, not an integer: typing 200 stores the character '2' (ASCII 50) and leaves 00 in the input stream. So changing only the type does not make the input correct. The safe pattern is to read into an int, validate 0 to 200, and only then store in the smallest type that is guaranteed to hold the range.
2. Kannada names appear as '?' while English names work. Explain the cause and give a standard C++ fix. Why does enlarging char name[20] to char name[100] not help?
Read the worked answer
The cause is encoding, not capacity. A char holds one byte. The console's default code page maps byte values to glyphs; English letters are present in ASCII, but Kannada code points are not, so the runtime substitutes '?'. Enlarging char name[20] to char name[100] only allows more bytes; it does not add Kannada glyphs to the code page. If the program used UTF-8, a Kannada character would occupy multiple bytes, so a 20-byte array could hold only a few Kannada characters and could truncate a name mid-character. A standard C++ approach is to store text in std::wstring/wchar_t and use wide streams (wcin, wcout), with a locale that supports the script; a more portable design is to keep UTF-8 in std::string and write to a UTF-8 file or use a Unicode-aware console library. The exam should accept the key distinction: character repertoire and encoding versus array length.
3. The student says, 'I will use int for attendance and string for names; then I never need to think about representation.' Evaluate this for a file that stores 1,000 student records and must be read by a program on another machine. Give one case where int is still the wrong choice.
Read the worked answer
Using int and std::string removes the immediate range and single-byte text problems, but it does not remove representation decisions from file storage. If the file is written as raw structs, the size of int is implementation-defined, byte order may differ, and struct padding may insert unused bytes; a program on another machine can misread the file. std::string objects cannot be written directly as raw bytes either. For 1,000 records the memory saved by char over int is only about 3 KB, so memory is not the main reason to choose a narrow type; correctness and a defined file format are. A fixed-width type such as int32_t plus a defined encoding, or a text format, is safer. int is still wrong when the value must be an exact 8-bit field in a hardware register or file header, or when it must represent a value outside its range; for attendance, a validated unsigned char or int is fine.