Signed vs unsigned behavior on 8-bit MCU in Embedded C - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of signed and unsigned addition on 8-bit MCU

What is the output of this code snippet running on an 8-bit microcontroller where char is 8 bits?

Embedded C

#include <stdio.h>

int main() {
    unsigned char a = 250;
    signed char b = 10;
    unsigned char c = a + b;
    printf("%u\n", c);
    return 0;
}

A 4

B 250

C 10

D 260

💡 Hint

Remember that unsigned char wraps around at 255.

Adding 250 + 10 = 260. Since unsigned char can only hold 0-255, it wraps around modulo 256. 260 - 256 = 4.

❓ Predict Output

intermediate

Signed overflow behavior on 8-bit MCU

What is the output of this code snippet on an 8-bit MCU where char is signed 8-bit?

Embedded C

#include <stdio.h>

int main() {
    signed char x = 127;
    signed char y = 1;
    signed char z = x + y;
    printf("%d\n", z);
    return 0;
}

A 127

B 128

C 0

D -128

💡 Hint

Think about signed overflow and two's complement wrap-around.

Adding 127 + 1 causes signed overflow. On 8-bit signed char, max is 127, so it wraps to -128.

🔧 Debug

advanced

Why does this unsigned subtraction produce a large number?

Consider this code on an 8-bit MCU:

#include <stdio.h>

int main() {
    unsigned char a = 5;
    unsigned char b = 10;
    unsigned char c = a - b;
    printf("%u\n", c);
    return 0;
}

Why does it print 251 instead of a negative number?

A Because the compiler converts unsigned to signed before subtraction

B Because the printf format specifier is wrong and prints garbage

C Because unsigned subtraction wraps around modulo 256, so 5 - 10 = 251

D Because the MCU does not support subtraction on unsigned types

💡 Hint

Think about how unsigned arithmetic works on small fixed-size types.

Unsigned arithmetic wraps modulo 256 on 8-bit types. So 5 - 10 = -5 mod 256 = 251.

❓ Predict Output

advanced

Result of mixed signed and unsigned comparison

What is the output of this code on an 8-bit MCU?

Embedded C

#include <stdio.h>

int main() {
    signed char a = -1;
    unsigned char b = 255;
    if (a == b) {
        printf("Equal\n");
    } else {
        printf("Not Equal\n");
    }
    return 0;
}

A Not Equal

B Equal

C Compilation error

D Undefined behavior

💡 Hint

Integer promotions: both char types promote to signed int. -1 != 255.

Both operands undergo integer promotions to int: signed char -1 becomes int -1 (sign-extended), unsigned char 255 becomes int 255. Since -1 != 255, it prints "Not Equal".

🧠 Conceptual

expert

Why is signed integer overflow undefined but unsigned overflow well-defined?

On an 8-bit MCU, why does C define signed integer overflow as undefined behavior, but unsigned integer overflow wraps around modulo 256?

A Because the compiler automatically converts signed overflow to unsigned overflow internally

B Because unsigned overflow is defined by the C standard to wrap modulo 2^n, but signed overflow can cause unpredictable hardware states and is left undefined for optimization

C Because signed integers use two's complement and unsigned integers use sign-magnitude representation

D Because unsigned integers are stored differently in memory than signed integers

💡 Hint

Think about the C language standard and hardware behavior.

The C standard defines unsigned overflow as modulo arithmetic to allow predictable wrap-around. Signed overflow is undefined to allow compilers to optimize and because hardware behavior can vary.