应该更改像这样的字符串的内容会导致exception吗？
请考虑以下代码：
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; } } 通过运行此代码，我们可以更改字符串的内容而不会发生exception。 我们没有必要声明任何不安全的代码。 这段代码显然非常狡猾！
我的问题很简单：你认为上面的代码应该抛出exception吗？
[编辑方面1：请注意，其他人已经为我尝试了这个，有些人得到了不同的结果 – 考虑到我正在做的事情，这并不太令人惊讶……;）
[EDIT2：请注意我在Windows 7 Ultimate 64位上使用Visual Studio 2010]
[EDIT3：制作测试字符串const，只是为了让它变得更加狡猾！]
我对使FieldOffset不安全的投票。
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确保引用赋值保持primefaces性。 规则2说明为什么你可以做你做的，任何对象类型引用可能重叠。 不允许使用值类型值重叠，这会搞乱垃圾收集器。 规则3说明了后果， 它只使类型不可validation。
否则，这不是在没有unsafe关键字的情况下搞砸字符串的唯一方法。 只需调用一个踩踏字符串的函数。 它获取指向GC堆或加载器堆（内部字符串）上的字符串内容的指针，不进行复制。 这也是无法validation的代码，在沙盒中运行时也是无法利用的。
推动归宿：C＃ unsafe关键字与CLR认为可validation的内容完全无关，因此实际上是安全的代码。 它使用指针或自定义值类型（固定）来处理明显的情况。 这是否是C＃语言规范中的漏洞是值得商榷的。 Pinvoke是更明显的边缘情况。 对操作系统function进行调整非常安全。 对一些第三方C库进行分配不是。
但是我必须同意@fej，[FieldOffset]应该得到“你确定”的待遇。 太糟糕了，没有语法。 不可否认，我还没弄清楚为什么这实际上需要影响托管布局。 更有意义的是，此属性仅适用于封送布局。 很奇怪，也许有人在早期拿着一个王牌。