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

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;
    }
}

通过运行此代码,我们可以更改字符串的内容而不会发生异常.我们没有必要声明任何不安全的代码.这段代码显然非常狡猾!

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

[编辑方面1:请注意,其他人已经为我尝试了这个,有些人得到了不同的结果 - 考虑到我正在做的事情,这并不太令人惊讶......;)

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

但我不得不同意@fej,[FieldOffset]应该得到"你确定"的待遇.太糟糕了,没有语法.不可否认,我还没弄清楚为什么这实际上需要影响托管布局.它将使很多更有意义,这种特征将仅适用于编组布局.很奇怪,也许有人在早期拿着王牌.

Answer 2

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