修改C#固定大小缓冲区长度未触发越界异常的原因咨询

Let's break down what's happening here—this is a common point of confusion when working with unsafe C# code, so your question makes total sense.

First, here's your modified code for reference:

using System;
namespace Page189 {
    unsafe struct UnsafeUnicodeString {
        public short Length;
        public fixed byte Buffer[1]; // Modified from original 30-length buffer
        unsafe class UnsafeClass {
            UnsafeUnicodeString uus;
            public UnsafeClass(string s) {
                uus.Length = (short) s.Length;
                fixed (byte* p = uus.Buffer)
                    for (int i = 0; i < s.Length; i++) {
                        p[i] = (byte) s[i];
                        Console.Write((char)p[i]);// Custom debug output
                    }
            }
        }
        class Test {
            static void Main() {
                new UnsafeClass("Christian Troy");
            }
        }
    }
}

You expected a memory access exception when writing way past the 1-byte Buffer limit, but the program ran without errors. Here's why:

1. Unsafe code opts out of CLR safety checks #

When you use the unsafe keyword in C#, you're explicitly telling the runtime: "I'm taking full responsibility for memory safety here." Unlike safe managed arrays (where accessing an index beyond the array length throws an IndexOutOfRangeException), fixed buffers in unsafe structs don't get automatic boundary checking from the CLR. The runtime assumes you know exactly what you're doing with raw pointers.

2. Memory corruption doesn't always trigger immediate errors #

Your code is definitely corrupting memory—you're writing bytes past the 1-byte Buffer into whatever memory happens to follow the UnsafeUnicodeString instance. The lack of an immediate error is a case of undefined behavior:

• The memory you're overwriting might be unused (free) space in the process's heap or stack, so nothing critical gets broken right now.
• Or it could be memory belonging to another object, but that object hasn't tried to read or write that portion of memory yet. When it does, you'll get mysterious bugs (like unexpected values, random crashes, or data corruption) that are notoriously hard to debug.

3. How to catch these issues during development #

If you want to detect out-of-bounds memory accesses like this:

• Add manual boundary checks in your unsafe code (e.g., verify that i < 1 before writing to p[i]—since fixed buffers don't expose a Length property, you'll need to track the size yourself).
• Use debugging tools like Visual Studio's AddressSanitizer (available for .NET 5+) or Windows' Application Verifier, which are built to catch these kinds of memory violations.

内容的提问来源于stack exchange，提问作者Huibin Zhang