我刚刚发现了一些令我震惊的事情。现在回想起来，我觉得自己很天真，没有早点看到这一点，但同时，它仍然让我感到震惊。
我们从 C# 调用本机 (C++) 代码。目前，我们使用 P/Invoke 和/或 C++/CLI 进行测试。在这两种技术中，我们发现可以将指向托管内存的指针传递给本机代码，并在本机代码中执行越界读取或写入访问！
读取或写入访问并不总是会终止应用程序，有时不会导致任何错误。因此，我认为没有针对这种情况的保障措施？
虽然我可以理解任何类型的内存保护都可能会带来（可能很大的）运行时损失，但我们似乎以如此简单的方式规避了 C# 的内存保护，这仍然让我感到惊讶。我们的 C# 代码和本机绑定没有以任何方式标记为
unsafe我并不是想在这里批评 C#。可能，这是本机集成可以工作的唯一方法，或者至少是具有良好性能的唯一方法（？）但我仍然有点震惊，这种“问题”在任何有关 P/ 的页面中都没有讨论过Invoke 和我一直在读的C++/CLI。我想知道，为什么不是所有本机代码都是隐式的
unsafe最后，如果有任何方法可以防止这种情况发生，那就太好了。不可否认，在内存写保护方面我非常天真。我知道操作系统会防止写入不属于该进程的内存。然而，我们是否处于同一个过程中？有没有办法（特别是在 Windows 中）禁止本机代码写入任何托管内存？
是的，这是正确的。但所有本机代码都是隐式不安全的，并且因为它是隐式不安全的，所以不需要特殊的关键字。
如果您调用本机代码或任何代码，您相信它会执行预期的操作。请记住，托管内存不是一项安全功能，而是一种有助于避免错误的辅助功能。这个功能显然在本机代码中不可用。
如果这对您来说是个问题，解决方案是将有问题的代码移至另一个进程，并使用某种形式的 IPC 与进程进行通信。这增加了一些复杂性，但这是必要的权衡。