What is sign extension, and what goes wrong when a negative 16-bit value is widened to 32 bits by zero-filling?

## Widening and the two fill rules **Widening** stores a narrow integer in a wider one — 16 bits into 32, 8 into 64. The low bits copy across unchanged; the question is what fills the new high-order bits. - **Zero extension**: fill with zeros. Correct for **unsigned** values, whose value is just the sum of positive place weights — leading zeros change nothing. - **Sign extension**: fill with **copies of the sign bit**. Correct for **signed** two's-complement values. For a non-negative signed value the two rules coincide (the sign bit is 0). They diverge exactly when the value is negative. ## Why replicating the sign bit preserves the value In 16 bits, the top bit carries weight -2^15. After widening to 32 bits, that position's weight becomes an ordinary +2^15, and the new top bit carries -2^31. Fill bits 16..31 with ones (for a negative value) and their combined contribution is: ``` -2^31 + (2^30 + 2^29 + ... + 2^16 + 2^15) = -2^15 ``` — exactly the weight the old sign bit used to carry. The geometric run of ones plus the new negative top weight telescopes back to the original contribution, so the value is unchanged. This is also why a negative number's wide form is a long run of leading ones: -200 is `0xFF38` in 16 bits and `0xFFFFFF38` in 32. ## The classic bug: assembling samples from raw bytes A firmware payload delivers a signed 16-bit temperature sample as two bytes. Each byte reads as 0..255, and the assembly looks innocent: ``` high = payload[k] // 0..255 low = payload[k + 1] // 0..255 sample = high * 256 + low // held in a 32-bit variable ``` For a reading of -20.0 degrees (stored as -200 in tenths), the wire bytes are `0xFF` and `0x38`. The arithmetic yields 255*256 + 56 = **65336** — a huge positive — because nothing ever told the 32-bit variable that bit 15 of the assembled pattern was a *sign* bit. Every reading below zero arrives as a value slightly under 65536, which is precisely the symptom to recognize: negatives showing up as `65536 + value`. ## The fix, portably After assembling an n-bit signed value into an unsigned reading `u`: ``` if u >= 2^(n-1): value = u - 2^n else: value = u ``` For n = 16: 65336 >= 32768, so value = 65336 - 65536 = **-200**. This subtraction is the arithmetic form of sign extension — it converts the unsigned reading of a pattern into its two's-complement reading. Equivalently, one can replicate bit 15 into bits 16..31 with masks. Statically typed languages sign-extend automatically when widening a *signed* type — a 16-bit signed value assigned into a 32-bit one in Go or Java carries its sign — which is exactly why the bug hides in *byte-level* code: the bytes are small non-negative numbers, so the type system never knows a sign bit exists. Environments where wire bytes surface as plain numbers, such as decoding binary payloads in Python or JavaScript, must always apply the subtraction manually. ## The mirror image: narrowing Going the other way — 32 bits into 16 — is **truncation**: the high bits are dropped. That is not a fill-rule question but a range question (the value may simply not fit), and its failure modes belong with overflow. The asymmetry is worth stating in an interview: widening is always value-preserving *if you pick the right fill*, narrowing is only safe when the value already fits the narrow range.