除了你自己的程序，我不认为你会破坏任何东西，在最坏的情况下，你会尝试从一个内存地址读取或写入一个页面，内核没有分配给你的进程，产生适当的异常并被杀死(我的意思是，你的进程)。

我正在使用一个用于DSP芯片的编译器，该编译器故意生成代码，从C代码中访问一个数组的末尾，而C代码没有!

这是因为循环是结构化的，因此迭代结束时将为下一次迭代预取一些数据。因此，在最后一次迭代结束时预取的数据实际上从未被使用。

编写这样的C代码会调用未定义的行为，但这只是一个标准文档的形式，它关注的是最大的可移植性。

更常见的情况是，访问越界的程序没有被巧妙地优化。它只是有bug。代码获取一些垃圾值，并且与前面提到的编译器的优化循环不同，代码随后在后续计算中使用该值，从而破坏了它们。

捕获这样的错误是值得的，因此即使仅仅为了这个原因，也值得使行为未定义:这样运行时就可以产生类似“main.c第42行数组溢出”这样的诊断消息。

在具有虚拟内存的系统上，分配数组时，后面的地址可能位于虚拟内存的未映射区域。访问将轰炸程序。

说句题外话，请注意，在C语言中，我们允许创建一个指针，它位于数组的末尾之后。这个指针必须比任何指向数组内部的指针都要大。 这意味着C实现不能将数组放在内存的末尾，在那里，1 +地址会被环绕，看起来比数组中的其他地址更小。

Nevertheless, access to uninitialized or out of bounds values are sometimes a valid optimization technique, even if not maximally portable. This is for instance why the Valgrind tool does not report accesses to uninitialized data when those accesses happen, but only when the value is later used in some way that could affect the outcome of the program. You get a diagnostic like "conditional branch in xxx:nnn depends on uninitialized value" and it can be sometimes hard to track down where it originates. If all such accesses were trapped immediately, there would be a lot of false positives arising from compiler optimized code as well as correctly hand-optimized code.

Speaking of which, I was working with some codec from a vendor which was giving off these errors when ported to Linux and run under Valgrind. But the vendor convinced me that only several bits of the value being used actually came from uninitialized memory, and those bits were carefully avoided by the logic.. Only the good bits of the value were being used and Valgrind doesn't have the ability to track down to the individual bit. The uninitialized material came from reading a word past the end of a bit stream of encoded data, but the code knows how many bits are in the stream and will not use more bits than there actually are. Since the access beyond the end of the bit stream array does not cause any harm on the DSP architecture (there is no virtual memory after the array, no memory-mapped ports, and the address does not wrap) it is a valid optimization technique.

“未定义的行为”并没有多大意义，因为根据ISO C，简单地包含一个C标准中没有定义的头文件，或者调用一个程序本身或C标准中没有定义的函数，都是未定义行为的例子。未定义的行为并不意味着“没有被地球上的任何人定义”，而是“没有被ISO C标准定义”。当然，有时候未定义的行为是绝对没有人能定义的。

Objective-C中的nsarray被分配一个特定的内存块。超过数组的边界意味着您将访问没有分配给数组的内存。这意味着:

This memory can have any value. There's no way of knowing if the data is valid based on your data type. This memory may contain sensitive information such as private keys or other user credentials. The memory address may be invalid or protected. The memory can have a changing value because it's being accessed by another program or thread. Other things use memory address space, such as memory-mapped ports. Writing data to unknown memory address can crash your program, overwrite OS memory space, and generally cause the sun to implode.

从程序的角度来看，您总是想知道代码何时超出了数组的边界。这可能导致返回未知值，导致应用程序崩溃或提供无效数据。

在测试代码时，您可能想尝试使用Valgrind中的memcheck工具——它不会捕获堆栈框架内的单个数组边界违规，但它应该捕获许多其他类型的内存问题，包括那些会导致单个函数范围之外的微妙、更广泛的问题的问题。

摘自手册:

Memcheck is a memory error detector. It can detect the following problems that are common in C and C++ programs. Accessing memory you shouldn't, e.g. overrunning and underrunning heap blocks, overrunning the top of the stack, and accessing memory after it has been freed. Using undefined values, i.e. values that have not been initialised, or that have been derived from other undefined values. Incorrect freeing of heap memory, such as double-freeing heap blocks, or mismatched use of malloc/new/new[] versus free/delete/delete[] Overlapping src and dst pointers in memcpy and related functions. Memory leaks.

ETA:不过，正如卡兹的回答所说，它不是万能的，并且并不总是提供最有帮助的输出，特别是当您使用令人兴奋的访问模式时。

如果您曾经做过系统级编程或嵌入式系统编程，如果您随机写入内存位置，可能会发生非常糟糕的事情。旧系统和许多微控制器使用内存映射IO，因此写入映射到外设寄存器的内存位置可能会造成严重破坏，特别是如果它是异步完成的。

一个例子是编程闪存。内存芯片上的编程模式是通过将特定的值序列写入芯片地址范围内的特定位置来实现的。如果在此期间另一个进程写入芯片中的任何其他位置，则会导致编程周期失败。

在某些情况下，硬件会将地址环绕起来(地址中最重要的位/字节会被忽略)，因此写入超出物理地址空间末端的地址实际上会导致数据在中间写入。

最后，像MC68000这样的老cpu可能会锁定到只有硬件重置才能让它们重新工作的地步。我已经几十年没有使用它们了，但我相信当它在试图处理异常时遇到总线错误(不存在内存)时，它会简单地停止，直到断言硬件重置。

我最大的建议是为一个产品做一个明显的宣传，但我个人对此没有兴趣，我也不以任何方式与他们联系——但基于几十年的C编程和嵌入式系统，可靠性是至关重要的，Gimpel的PC Lint不仅可以检测这类错误，还可以通过不断地唠叨你的坏习惯，让你成为更好的C/ c++程序员。

我还建议你阅读MISRA C编码标准，如果你能从别人那里得到一份的话。我没有看到最近的任何一个，但在过去的日子里，他们给了一个很好的解释，为什么你应该/不应该做他们覆盖的事情。

我不知道你的情况，但当我第二次或第三次从任何应用程序中得到一个coredump或挂起时，我对任何公司的看法都会下降一半。第四次或第五次，不管是什么包装都变成了架子，我用一根木桩穿过包装/光盘的中心，只是为了确保它永远不会回来缠着我。

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

行为，在使用不可移植或错误的程序构造或 错误的数据，本标准没有规定 需求

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

可能的未定义行为包括忽略情况 翻译过程中的行为完全无法预测结果 或以文件化的方式执行程序的特点 环境(有或没有发出诊断消息)，到 终止翻译或执行(通过发出 诊断消息)。

这就是理论。现实是什么?

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

That's assuming your program is running under an operating system that attempts to protect concurrently running processes from each other. If your code is running on the "bare metal", say if it's part of an OS kernel or an embedded system, then there is no such protection; your misbehaving code is what was supposed to provide that protection. In that case, the possibilities for damage are considerably greater, including, in some cases, physical damage to the hardware (or to things or people nearby).

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

(一个历史上的例子:我听说在一些具有核心内存的旧系统上，在一个紧密循环中重复访问单个内存位置可能会导致内存块融化。其他的可能性包括损坏CRT显示器，以驱动器柜的谐波频率移动磁盘驱动器的读写头，导致它走过桌子，掉到地板上。)

而且还要担心天网。

底线是这样的:如果你可以编写一个程序故意做一些不好的事情，那么至少在理论上，一个有bug的程序可能会意外地做同样的事情。

实际上，在MacOS X系统上运行的有bug的程序不太可能出现比崩溃更严重的情况。但是完全阻止有bug的代码做一些非常糟糕的事情是不可能的。