我只是想为这个问题添加一些实际的例子——想象一下下面的代码:

#include <stdio.h>

int main(void) {
    int n[5];
    n[5] = 1;

    printf("answer %d\n", n[5]);

    return (0);
}

它具有未定义的行为。例如，如果你启用了clang优化(-Ofast)，结果会是这样的:

answer 748418584

(如果你没有编译，可能会输出答案1的正确结果)

这是因为在第一种情况下，赋值给1的函数实际上从未在最终代码中组装(您也可以查看godbolt asm代码)。

(然而，必须注意的是，根据这种逻辑，main甚至不应该调用printf，所以最好的建议是不要依赖于优化器来解决你的UB -而是要知道有时它可能会以这种方式工作)

这里的结论是，现代C优化编译器将假设未定义的行为(UB)永远不会发生(这意味着上面的代码将类似于(但不相同):

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int n[5];

    if (0)
        n[5] = 1;

    printf("answer %d\n", (exit(-1), n[5]));

    return (0);
} 

相反，这是完全定义的)。

这是因为第一个条件语句从来没有达到它的真状态(0总是假的)。

在printf的第二个参数上，我们有一个序列点，在此之后，我们调用exit，程序在调用第二个逗号操作符中的UB之前终止(因此它的定义很好)。

所以第二个结论是，只要没有求值，UB就不是UB。

此外，我没有看到这里提到有相当现代的未定义行为消毒器(至少在clang)(选项-fsanitize= Undefined)将在第一个例子(但不是第二个)上给出以下输出:

/app/example.c:5:5: runtime error: index 5 out of bounds for type 'int[5]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:5:5 in 
/app/example.c:7:27: runtime error: index 5 out of bounds for type 'int[5]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:7:27 in 

以下是godbolt的所有样品:

https://godbolt.org/z/eY9ja4fdh(第一个示例，没有标记)

https://godbolt.org/z/cGcY7Ta9M(第一个示例和-Ofast clang)

https://godbolt.org/z/cGcY7Ta9M(第二个例子和UB消毒剂打开)

https://godbolt.org/z/vE531EKo4(第一个例子和UB消毒剂打开)

在测试代码时，您可能想尝试使用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:不过，正如卡兹的回答所说，它不是万能的，并且并不总是提供最有帮助的输出，特别是当您使用令人兴奋的访问模式时。

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

不以根用户或其他特权用户身份运行程序不会对任何系统造成损害，因此通常这可能是一个好主意。

通过将数据写入某个随机的内存位置，你不会直接“破坏”计算机上运行的任何其他程序，因为每个进程都运行在自己的内存空间中。

如果你试图访问任何没有分配给你的进程的内存，操作系统将停止你的程序执行分割错误。

因此，直接(无需以根用户身份运行并直接访问/dev/mem之类的文件)，您的程序不会干扰在您的操作系统上运行的任何其他程序。

尽管如此——这可能是你听说过的危险——盲目地将随机数据写入随机的内存位置，你肯定会损坏任何你能损坏的东西。

例如，您的程序可能希望删除存储在程序某处的文件名所给出的特定文件。如果你不小心覆盖了文件名所在的位置，你可能会删除一个完全不同的文件。

就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的代码做一些非常糟糕的事情是不可能的。

我只是想为这个问题添加一些实际的例子——想象一下下面的代码:

#include <stdio.h>

int main(void) {
    int n[5];
    n[5] = 1;

    printf("answer %d\n", n[5]);

    return (0);
}

它具有未定义的行为。例如，如果你启用了clang优化(-Ofast)，结果会是这样的:

answer 748418584

(如果你没有编译，可能会输出答案1的正确结果)

这是因为在第一种情况下，赋值给1的函数实际上从未在最终代码中组装(您也可以查看godbolt asm代码)。

(然而，必须注意的是，根据这种逻辑，main甚至不应该调用printf，所以最好的建议是不要依赖于优化器来解决你的UB -而是要知道有时它可能会以这种方式工作)

这里的结论是，现代C优化编译器将假设未定义的行为(UB)永远不会发生(这意味着上面的代码将类似于(但不相同):

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int n[5];

    if (0)
        n[5] = 1;

    printf("answer %d\n", (exit(-1), n[5]));

    return (0);
} 

相反，这是完全定义的)。

这是因为第一个条件语句从来没有达到它的真状态(0总是假的)。

在printf的第二个参数上，我们有一个序列点，在此之后，我们调用exit，程序在调用第二个逗号操作符中的UB之前终止(因此它的定义很好)。

所以第二个结论是，只要没有求值，UB就不是UB。

此外，我没有看到这里提到有相当现代的未定义行为消毒器(至少在clang)(选项-fsanitize= Undefined)将在第一个例子(但不是第二个)上给出以下输出:

/app/example.c:5:5: runtime error: index 5 out of bounds for type 'int[5]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:5:5 in 
/app/example.c:7:27: runtime error: index 5 out of bounds for type 'int[5]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:7:27 in 

以下是godbolt的所有样品:

https://godbolt.org/z/eY9ja4fdh(第一个示例，没有标记)

https://godbolt.org/z/cGcY7Ta9M(第一个示例和-Ofast clang)

https://godbolt.org/z/cGcY7Ta9M(第二个例子和UB消毒剂打开)

https://godbolt.org/z/vE531EKo4(第一个例子和UB消毒剂打开)