c - 越界访问数组有多危险？

Question

访问超出数组范围的数组(在 C 语言中)有多危险？有时可能会发生我从数组外部读取的情况(我现在知道我然后访问程序的其他部分甚至超出范围使用的内存)，或者我尝试将值设置为数组外部的索引。程序有时会崩溃，但有时只是运行，只会给出意想不到的结果。

现在我想知道的是，这到底有多危险？如果它损坏了我的程序，那也不算太糟糕。另一方面，如果它破坏了我的程序之外的某些东西，因为我以某种方式设法访问了一些完全不相关的内存，那么我想这是非常糟糕的。 我读了很多“任何事情都可能发生”，'segmentation might be the least bad problem' ，“你的硬盘可能会变成粉红色， unicorn 可能会在你的窗下唱歌”，这一切都很好，但真正的危险是什么？

我的问题:

1. 从数组外部读取值是否会损坏任何东西 除了我的程序？我想只要看看事物就可以了 不改变任何东西，或者例如会改变“最后一次” 我碰巧到达的文件的“opened”属性？
2. 将值设置在数组之外是否会损坏除我的之外的任何东西 程序？由此 Stack Overflow question我认为可以访问 任何内存位置，都没有安全保证。
3. 我现在在 XCode 中运行我的小程序。是这样吗 为我的程序提供一些无法提供的额外保护 到达自己的内存之外？它会损害 XCode 吗？
4. 关于如何安全地运行存在固有缺陷的代码有什么建议吗？

我使用 OSX 10.7、Xcode 4.6。

Answer 1

就 ISO C 标准(该语言的官方定义)而言，访问其边界之外的数组具有“未定义的行为”。其字面意思是:

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

非规范性注释对此进行了扩展:

Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

这就是理论。事实真相又如何？

在“最佳”情况下，您将访问一些内存，这些内存要么属于您当前正在运行的程序(这可能会导致您的程序行为异常)，要么不属于您当前运行的程序。正在运行的程序(这可能会导致您的程序因段错误等原因而崩溃)。或者您可能尝试写入程序拥有的内存，但该内存被标记为只读；这也可能会导致您的程序崩溃。

假设您的程序正在操作系统下运行，该操作系统试图保护同时运行的进程免受彼此的影响。如果您的代码在“裸机”上运行，例如它是操作系统内核或嵌入式系统的一部分，那么就没有这样的保护；您行为不当的代码应该提供这种保护。在这种情况下，造成损坏的可能性要大得多，包括在某些情况下对硬件(或附近的事物或人)造成物理损坏。

即使在 protected 操作系统环境中，保护也并不总是 100%。例如，存在一些操作系统错误，允许非特权程序获得根(管理)访问权限。即使具有普通用户权限，出现故障的程序也可能会消耗过多的资源(CPU、内存、磁盘)，甚至可能导致整个系统瘫痪。许多恶意软件(病毒等)利用缓冲区溢出来获得对系统的未经授权的访问。

(一个历史例子:我听说在一些带有 core memory 的旧系统上，在紧密循环中重复访问单个内存位置实际上可能会导致该内存块融化。其他可能性包括破坏 CRT 显示器，并以驱动器机柜的谐波频率移动磁盘驱动器的读/写头，使其穿过 table 并掉落到地板上。)

总有 Skynet担心。

底线是这样的:如果你可以编写一个程序来故意做一些坏事，那么至少从理论上来说，一个有缺陷的程序也可能意外地做同样的事情.

实际上，在 MacOS X 系统上运行的有缺陷的程序非常不太可能发生比崩溃更严重的事情。但不可能完全阻止有错误的代码做出真正糟糕的事情。