Base CS from zero
Types interpret bits
The previous lesson ended with an unanswered problem: a memory cell holds the bit pattern
01000001, but that pattern by itself means nothing. You need to know how to read it.
The unit on “encoding the world” already showed you the mechanism: to represent a number, apply binary place-value; to represent a letter, look it up in an encoding table like ASCII; to represent a colour, split 8 bits into a red component and a blue component and so on. Each of those was a different rule for reading the same kind of bit sequence.
The word for such a rule is type. A type is the interpretation rule that the program applies to a bit pattern to produce a value with meaning. This lesson makes that concept precise and shows what follows from it.
After this lesson you can define a type as an interpretation rule for bit patterns, demonstrate that the same bit pattern produces different values under different types, explain what “applying a type” means in terms of what the machine does, and describe the relationship between a type, a bit pattern, and a value.
A type is an interpretation rule. When a program reads bits from memory, it must also know how to interpret those bits. A type is precisely that knowledge: a formal rule that maps a bit pattern to a value in some domain.
The rule has two components:
- Size — how many bytes the value occupies.
- Interpretation — what the bit pattern at those bytes means (an integer using place-value, a character using an encoding table, a fraction using IEEE 754 floating point, and so on).
Without both components, you cannot read a value correctly. Knowing the address is not enough; knowing the type is equally necessary.
The same bits, different types. Consider the single byte 01000001. Under three
different type rules:
- Unsigned 8-bit integer (
u8): place-value binary. Result: 65. - ASCII character (
char): look up code 65 in the ASCII table. Result: ‘A’. - Part of a 3-byte RGB colour: this byte might be the red channel. Result: a red intensity of 65 out of 255 (roughly 25% red).
The physical bits in the cell are unchanged. The program switched its reading rule. Three types; three values; one bit pattern. This is not a bug — it is the mechanism that allows a single physical memory to represent infinitely many kinds of data.
Applying a type: what the machine does. When a program “applies a type” to a bit pattern, it runs the appropriate decoding algorithm:
- For an integer: feed the bits into a binary-to-decimal (or binary-to-computation) algorithm, treating the bit positions as powers of 2 (or applying two’s complement for signed values).
- For a character: treat the bits as an index into an encoding table (ASCII, UTF-8).
- For a floating-point number: split the bits into sign, exponent, and mantissa fields according to the IEEE 754 standard.
In each case, the machine’s ALU (arithmetic logic unit) or the runtime’s decoding routines perform this calculation. The bits do not change. The output — the usable value — depends entirely on which algorithm was invoked.
Types are properties of the program, not of the bits. A critical consequence: the bits in a memory cell have no type label. A cell does not say “I am an integer” or “I am a character.” The type is tracked by the program (or the compiler, or the runtime) separately from the bits.
In a statically typed language like TypeScript in “strict” mode, the compiler records for every variable what type it holds, and refuses to let you read an integer variable as a character. In a dynamically typed language, the runtime attaches a type tag to each value at run time. In a language like C, the programmer bears the full responsibility — the compiler trusts you to apply the right type, and if you get it wrong, the bits are misread silently.
The bits are always just bits. The type discipline is the layer that keeps programs from misreading them.
Why this works
Why does this matter at the level of a practical programmer? Every time you pass data across a boundary — write a JSON field, read a binary file, call a foreign function interface — you are negotiating a type agreement. If both sides agree on the type rule, communication is correct. If they disagree, the bits are the same on the wire but their meaning differs at each end. Type errors in networked systems, file format bugs, and binary serialisation issues all have this root cause: a mismatch between the type the writer applied and the type the reader applies.
Reading the same memory cell under two different types.
Memory state: cell at address 20 holds 01000001.
Reading as an unsigned 8-bit integer:
- The program issues: “load 1 byte at address 20, interpret as u8.”
- Decoding:
0×128 + 1×64 + 0×32 + 0×16 + 0×8 + 0×4 + 0×2 + 1×1 = 65. - Result: the integer 65.
Reading the same cell as an ASCII character:
- The program issues: “load 1 byte at address 20, interpret as an ASCII char.”
- Decoding: look up code point 65 in the ASCII table → the letter “A”.
- Result: the character ‘A’.
Same address. Same byte. Same eight off/on states in hardware. Two different type rules produce two different usable values: 65 and ‘A’. Both are “correct” given their respective rules. Neither answer is the “true” meaning of the byte — the meaning is entirely determined by the choice of type.
Now a write, for comparison:
Storing the character ‘B’ at address 20:
- ‘B’ has ASCII code 66. In 8-bit binary:
01000010. - The program issues: “store the byte
01000010at address 20.” - Cell 20 now holds
01000010. - A subsequent integer read of address 20 returns 66.
- A subsequent character read returns ‘B’.
The program stored a character and later read an integer from the same cell. Both operations are mechanically valid. Whether the result makes sense is up to the program — the hardware cannot know.
Common mistake
“A type tells you what a value is.” More precisely: a type tells you how to interpret
a bit pattern. The bits are what they are; the type is the lens. Saying “x is an integer”
means “the bits at x’s memory location should be decoded using integer arithmetic.” It
does not change the bits. This distinction matters when you cast a value in C or use
Buffer.readUInt8 versus Buffer.readInt8 in Node.js — you are switching the decoding
lens, not changing the underlying bytes.
The byte 01000010 at address 5 is read as an unsigned 8-bit integer. What is the result? (Bit positions from right: 1, 2, 4, 8, 16, 32, 64, 128.)
The ASCII code for 'B' is 66. If a byte holds the integer value 66 and is read as an ASCII character, what character does it represent? Enter the ASCII code of that character (which is 66).
A program writes the integer 0 (all bits zero: 00000000) to address 12. A second program reads address 12 as an ASCII character. The ASCII code 0 is a control character called NUL. How many bits are 1 in the byte 00000000?
Cell at address 10 holds bits 11111111. Read as unsigned 8-bit integer, this is 255 (all bits set). How many bytes does this single-byte value occupy?
A 2-byte (16-bit) unsigned integer starts at address 30 and occupies addresses 30 and 31. If both bytes are 00000001 (value 1 each), the 16-bit value is 1×256 + 1 = 257. How many total bytes does this 16-bit value occupy?
If a memory cell holds the bits 01000001 and a program reads it as a u8 integer, then another program reads the same cell as an ASCII character, what is true?
A type is an interpretation rule: it specifies the size of the bit pattern and how to decode those bits into a useful value (integer, character, colour, and so on). The same bit pattern produces different values under different types. Types are tracked by the program (compiler, runtime, or programmer), not embedded in the bits. The memory hardware stores and retrieves bit patterns without caring about their type. Understanding that a type is a reading rule — and that the bits are always raw — is the foundation for understanding every form of type error, type conversion, and binary data manipulation you will encounter in programming.