Undefined Behavior

What is Undefined Behavior?

Undefined behavior means the C++ standard doesn't specify what should happen. Your program might:

• Crash
• Produce random results
• Appear to work correctly (but fail later)
• Work on one computer but fail on another

What are Uninitialized Variables?

When you declare a variable without giving it an initial value, it contains garbage - whatever random data was previously stored in that memory location.

int x;             // Uninitialized - contains garbage!
std::cout << x;    // Undefined behavior - could print anything

Examples of Undefined Behavior

Using Uninitialized Variables

int count;                    // Uninitialized
std::cout << count + 10;      // May print 10 but is undefined behavior!

Math with Garbage Values

double price;                 // Contains garbage
double tax = price * 0.08;    // Undefined behavior!

Why This Happens

When variables are created:

1. Memory is allocated
2. But that memory isn't cleared
3. It contains whatever was there before
4. Could be any value!

The Solution: Always Initialize

Initialize When Declaring

// Traditional approach (older style)
int count = 0;
double price = 0.0;
bool isReady = false;
string name = "";

// Modern C++ (recommended) - uniform initialization
int count{};          // Initializes to 0
double price{};       // Initializes to 0.0
bool isReady{};       // Initializes to false
string name{};        // Initializes to empty string

// When you need specific values
int maxItems{100};
double taxRate{0.08};
bool debugMode{true};

Even "Temporary" Variables

// Bad
int temp;
std::cin >> temp;      // What if cin fails?

// Good
int temp{};            // Default initialized to 0
std::cin >> temp;      // Safe default value if input fails

Debug vs Release Builds

• Debug builds might initialize variables to 0 automatically
• Release builds typically don't
• Your program might work in debug but fail in release!

Implementation-Defined Behavior vs Undefined Behavior

While undefined behavior is unpredictable and dangerous, implementation-defined behavior is when the C++ standard allows different valid behaviors on different systems, but the behavior must be consistent and documented.

What is Implementation-Defined Behavior?

Implementation-defined behavior means the C++ standard says "this can vary between systems, but each system must:

1. Choose a specific behavior
2. Document what it does
3. Be consistent about it

Common Examples

Data Type Sizes

Remember the data types exercise? The sizes of int, long, and char are implementation-defined:

#include <iostream>

int main() {
    std::cout << "Size of int: " << sizeof(int) << " bytes" << std::endl;
    std::cout << "Size of long: " << sizeof(long) << " bytes" << std::endl;

    // These sizes can vary between systems!
    // On a 32-bit system: int might be 4 bytes
    // On some embedded systems: int might be 2 bytes
    // But it's guaranteed to be consistent within each system

    return 0;
}

Character Signedness

char c = 200;  // Implementation-defined: could be treated as -56 or 200
               // depending on whether char is signed or unsigned by default

Integer Overflow Behavior

unsigned int x = 4294967295;  // Maximum value for 32-bit unsigned int
x = x + 1;                    // Defined: wraps to 0

int y = 2147483647;           // Maximum value for 32-bit signed int
y = y + 1;                    // Implementation-defined: could wrap to negative
                             // or behave differently on different systems

Key Differences

Examples in Context

Undefined Behavior (Always Avoid):

int x;              // Uninitialized
std::cout << x;          // ❌ Could print anything, crash, or corrupt memory

Implementation-Defined Behavior (Plan For):

int x{42};
std::cout << sizeof(x);  // ✅ Will consistently print the same size on this system
                    // but might be different on another system

Connection to Data Types Exercise

In the Data Types exercise, you discovered that different systems show different sizes for data types. This wasn't a bug or error - it was implementation-defined behavior in action!

• Your system might show int as 4 bytes
• An embedded system might show int as 2 bytes
• A 64-bit system might show long as 8 bytes
• All are correct according to the C++ standard

This is why portable C++ code uses:

• Fixed-width types like int32_t when exact sizes matter
• Or works with the minimum guarantees (like int being at least 16 bits)

Best Practices for Implementation-Defined Behavior

1. Be aware it exists - especially with data type sizes
2. Test on target systems if portability matters
3. Use fixed-width types when exact sizes are critical
4. Document assumptions about system behavior
5. Don't confuse it with undefined behavior - implementation-defined is safe, undefined is not

Best Practices

1. Always initialize variables when you declare them
2. Use meaningful default values when needed
3. Initialize before first use
4. Use compiler warnings to catch uninitialized variables

Remember: A few extra characters typing {} can save hours of debugging!

Summary

• Undefined behavior occurs when the C++ standard doesn't specify what should happen - it's unpredictable and dangerous
• Uninitialized variables contain garbage values and lead to undefined behavior when used
• Always initialize variables when declaring them using {} (modern C++) or = (traditional)
• Implementation-defined behavior is different - it's predictable within each system but may vary between systems (like data type sizes)
• Use compiler warnings and test thoroughly to catch initialization issues
• Initialize even "temporary" variables to provide safe default values