像这样更改字符串的内容是不是会导致异常？

Posted 2023-02-18

【中文标题】像这样更改字符串的内容是不是会导致异常？

【英文标题】：Should changing the contents of a string like this cause an exception?像这样更改字符串的内容是否会导致异常？

【发布时间】：2011-05-30 00:10:35

【问题描述】：

考虑以下代码：

using System;
using System.Runtime.InteropServices;

namespace Demo

    class Program
    
        static void Main(string[] args)
        
            const string test = "ABCDEF"; // Strings are immutable, right?
            char[] chars = new StringToCharstr=test.chr;
            chars[0] = 'X';

            // On an x32 release or debug build or on an x64 debug build, 
            // the following prints "XBCDEF".
            // On an x64 release build, it prints "ABXDEF".
            // In both cases, we have changed the contents of 'test' without using
            // any 'unsafe' code...

            Console.WriteLine(test);
        
    

    [StructLayout(LayoutKind.Explicit)]
    public struct StringToChar
    
        [FieldOffset(0)]
        public string str;
        [FieldOffset(0)]
        public char[] chr;
    

通过运行此代码，我们能够更改字符串的内容而不会发生异常。我们不必为此声明任何不安全的代码。这段代码显然很狡猾！

我的问题很简单：你认为上面的代码应该抛出异常吗？

[EDIT1：请注意，其他人已经为我尝试过这个，有些人得到了不同的结果 - 考虑到我正在做的事情的讨厌，这并不太令人惊讶......;)]

[EDIT2：请注意，我在 Windows 7 Ultimate 64 位上使用 Visual Studio 2010]

[EDIT3：将测试字符串设为 const，只是为了让它更加狡猾！]

【问题讨论】：

question I already asked 的重复 :-)

非常有趣！看起来这是一个众所周知的问题。

【参考方案1】：

clr/src/vm/class.cpp 的 SSCLI20 源代码，MethodTableBuilder::HandleExplicitLayout 可以提供一些见解。评论异常多，此评论描述了规则（为便于阅读而编辑）：

// go through each field and look for invalid layout
// (note that we are more permissive than what Ecma allows. We only disallow 
// the minimum set necessary to close security holes.)
//
// This is what we implement:
//
// 1. Verify that every OREF is on a valid alignment
// 2. Verify that OREFs only overlap with other OREFs.
// 3. If an OREF does overlap with another OREF, the class is marked unverifiable.
// 4. If an overlap of any kind occurs, the class will be marked NotTightlyPacked (affects ValueType.Equals()).

规则 1 确保引用分配保持原子性。规则 2 说明了为什么你可以做你所做的，任何对象类型引用都可能重叠。不允许与值类型值重叠，这会搞砸垃圾收集器。规则 3 说明了结果，它仅使类型不可验证。

否则，如果没有 unsafe 关键字，这不是搞砸字符串的唯一方法。只需调用一个踩踏字符串的函数。它获取指向 GC 堆或加载器堆（内部字符串）上的字符串内容的指针，不进行复制。这也是无法验证的代码，并且在沙盒中运行时同样无法利用。

直奔主题：C# unsafe 关键字与 CLR 认为可验证的内容完全无关，因此实际上是安全的代码。它使用指针或自定义值类型（固定）处理明显的情况。这是否是 C# 语言规范中的泄漏是有争议的。 Pinvoke 是更明显的边缘情况。调用操作系统功能是非常安全的。不能调用某些 3rd 方 C 库。

但我必须同意@fej，[FieldOffset] 应该得到“你确定”的待遇。太糟糕了，没有语法。诚然，我还没有弄清楚为什么这实际上需要影响 managed 布局。 much 更有意义的是，此属性仅适用于编组布局。很奇怪，也许早期有人拿着王牌。

【讨论】：

“诚然，我还没有弄清楚为什么这实际上需要影响托管布局。[...] 很奇怪，也许早期有人拿着王牌。” - 但是值类型不是管理的（除非它们被装箱），我想知道是否有计划或设计允许类或结构直接对本机/Win32 代码进行 blittable （特别是考虑到结构重的 Win32 是) 甚至允许从本机代码和托管代码对内存中相同的结构或类进行并发/共享访问 - （此外，线程本地存储中的值类型是否“托管”？）

【参考方案2】：

我的投票是让 FieldOffset 变得不安全。

【讨论】：

是的，这似乎完全合适！