Implementing a Basic Undefined Behavior Sanitizer in Rust

This challenge asks you to create a rudimentary undefined behavior sanitizer (UBSan) for Rust. UBSan is a powerful tool that detects and reports undefined behavior (UB) at runtime, which is crucial for writing robust and secure code. By building a simplified version, you'll gain a deeper understanding of how these sanitizers work and the common pitfalls in Rust programming that lead to UB.

Problem Description

Your task is to create a Rust library that can detect and report specific types of undefined behavior that occur within a given piece of Rust code. This sanitizer will act as a runtime checker, intercepting potentially problematic operations and flagging them if they violate Rust's safety guarantees.

Key Requirements:

1. Intercepting Memory Access: Implement checks for out-of-bounds array access (both reads and writes).
2. Detecting Null Pointer Dereferences: Identify instances where a null pointer (represented typically by Option<T> being None when T is expected, or raw pointer manipulation) is dereferenced.
3. Reporting Mechanism: When UB is detected, the sanitizer should print a clear error message to stderr indicating the type of UB, the location (if possible), and a brief description. The program should then ideally terminate or enter a safe error state.
4. Minimal Performance Overhead: While not as optimized as production UBSan, your sanitizer should aim to introduce as little overhead as possible when no UB is detected.
5. Usability: The sanitizer should be designed in a way that it can be "wrapped around" or integrated with other Rust code to monitor its execution.

Expected Behavior:

• Safe Code: Code that exhibits no UB should run without any interference or warnings from the sanitizer.
• Unsafe Code with UB: Code that attempts an out-of-bounds access on a slice, dereferences a null pointer, or performs other detectable UB should trigger the sanitizer's reporting mechanism.

Edge Cases to Consider:

• Integer Overflow: Detecting signed integer overflow (e.g., i32::MAX + 1) and unsigned integer overflow (e.g., u32::MAX + 1). Note that Rust's default behavior for overflow is to panic in debug builds and wrap in release builds, so you'll need to specifically check for the wrapping behavior if you're targeting release-like conditions.
• Pointer Aliasing: While full pointer aliasing detection is complex, consider how to approach (or explicitly state limitations regarding) scenarios with multiple mutable references to the same data.
• unsafe Blocks: The sanitizer should focus on detectable UB within unsafe blocks, as this is where UB is most likely to occur. It should not aim to sanitize all unsafe code, but rather specific patterns that are known to cause UB.

Examples

Example 1: Out-of-bounds Array Access

// Assume this code is part of the program being sanitized.
// The sanitizer library will provide functions to wrap/instrument this.

fn main() {
    let mut data = vec![10, 20, 30];
    // This is an out-of-bounds write
    let index = 5;
    // In a real scenario, the sanitizer would hook this access.
    // For this example, we simulate the problem.
    if index < data.len() {
        data[index] = 40;
    } else {
        // Simulate the sanitizer detecting UB
        eprintln!("UB Detected: Out-of-bounds write at index {} for a vector of length {}.", index, data.len());
        // In a real sanitizer, this would cause a panic or program termination.
        panic!("Out-of-bounds write detected");
    }
}

Expected Sanitizer Output (if index were 5):

UB Detected: Out-of-bounds write at index 5 for a vector of length 3.
thread 'main' panicked at 'Out-of-bounds write detected', src/main.rs:XX:YY

Explanation: The code attempts to write to index 5 of a vector that only has indices 0, 1, and 2. This is a clear out-of-bounds access.

Example 2: Null Pointer Dereference (simulated)

Rust's Option<T> and Box<T> are generally safe. However, raw pointers can lead to null dereferences.

// Assume this code is part of the program being sanitized.

use std::ptr;

fn main() {
    let mut null_ptr: *mut i32 = ptr::null_mut();
    // This is a null pointer dereference
    unsafe {
        // In a real scenario, the sanitizer would hook this dereference.
        // For this example, we simulate the problem.
        if null_ptr.is_null() {
            eprintln!("UB Detected: Dereferencing a null pointer.");
            panic!("Null pointer dereference detected");
        } else {
            *null_ptr = 100;
        }
    }
}

Expected Sanitizer Output:

UB Detected: Dereferencing a null pointer.
thread 'main' panicked at 'Null pointer dereference detected', src/main.rs:XX:YY

Explanation: The code attempts to dereference a raw pointer that is explicitly null.

Example 3: Signed Integer Overflow

// Assume this code is part of the program being sanitized.

fn main() {
    let a: i32 = i32::MAX;
    let b: i32 = 1;
    // This operation will overflow
    let result = a.wrapping_add(b); // Use wrapping_add to avoid panic in debug

    // In a real scenario, the sanitizer would detect the wrap.
    // For this example, we simulate the problem.
    if a > 0 && b > 0 && result < 0 {
        eprintln!("UB Detected: Signed integer overflow ({} + {})", a, b);
        panic!("Signed integer overflow detected");
    }
}

Expected Sanitizer Output:

UB Detected: Signed integer overflow (2147483647 + 1)
thread 'main' panicked at 'Signed integer overflow detected', src/main.rs:XX:YY

Explanation: Adding 1 to i32::MAX results in a negative number due to integer overflow, which is undefined behavior in Rust for signed integers (though wrapping is the common compiler behavior).

Constraints

• The sanitizer should focus on a subset of common UB: out-of-bounds access, null pointer dereferences, and signed integer overflow.
• You are not expected to build a full-fledged compiler instrumentation tool. Focus on runtime checks that can be applied to existing Rust code.
• The sanitizer should ideally integrate with standard Rust features and potentially leverage #[cfg(debug_assertions)] or similar to control its activation.
• The solution should be written entirely in Rust.
• The primary goal is educational: understanding the detection mechanisms for UB.

Notes

• Consider how you might integrate your sanitizer. Could it be a macro? A special wrapper type? A trait?
• For memory access, think about how to intercept operations on Vec, slices (&[T], &mut [T]), and arrays. This will likely involve implementing Deref, DerefMut, or custom indexing methods.
• Detecting integer overflow often involves checking the operands and the result for specific patterns that indicate wrapping.
• This challenge is about detecting UB, not necessarily preventing it entirely or providing a universal solution. The goal is to build a demonstrative tool.
• You will need to use unsafe code within your sanitizer implementation to perform low-level checks, but the code being sanitized should be treated as user code.