Question

请考虑以下代码：

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 StringToChar{str=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，只是为了让它变得更加狡猾！]

Answer 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＃不安全的关键字与CLR认为可验证的内容完全无关，因此实际上是安全的代码。它使用指针或自定义值类型（固定）来处理明显的情况。这是否是C＃语言规范的泄漏是值得商榷的。 Pinvoke是更明显的边缘情况。对操作系统功能进行调整非常安全。对某些第三方C库进行排名不是。

但是我必须同意@fej，[FieldOffset]应该得到“你确定”的待遇。太糟糕了，没有语法。不可否认，我还没弄清楚为什么这实际上需要影响托管布局。如果此属性仅适用于封送布局，那么很多会更有意义。奇怪的是，有人可能会在早期拿着王牌袖手旁观。

Answer 2

我对使FieldOffset不安全的投票。

应该更改像这样的字符串的内容会导致异常吗？

2 个答案: